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 hat relied upon software may not adequately address issues discussed in the HTI–2 Proposed Rule related to this topic (89 FR 63591). For example, in scenarios where a health care provider may already be using health IT products to support a specific exchange or interaction in the prior authorization workflow, it may be difficult for such a provider to find or use distinct health IT products to support the remaining interactions of the prior authorization workflow. In this scenario, there is no guarantee that a health IT developer would agree to use the provider’s existing health IT product as relied upon software. As a result, we agree that additional flexibility within the Certification Program beyond relied upon software may be necessary to address certification for electronic prior authorization. recommended that ASTP/ONC allow developers to phase in availability of Health IT Modules meeting different parts of the electronic prior authorization workflow over time. Commenters stated that the workflow envisioned in the CRD, DTR, and PAS IGs is highly complex, and relies on advanced features such as CDS Hooks and Clinical Quality Language (CQL). Commenters noted that the Electronic that the workflow envisioned in the CRD, DTR, and PAS IGs is highly complex, and relies on advanced features such as CDS Hooks and Clinical Quality Language (CQL). Commenters noted that the Electronic Prior Authorization measures finalized for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category focused on the submission of a prior authorization request, suggesting that the functionality described in the PAS IG and the CRD IG will be the most immediately relevant to healthcare providers. Several commenters suggested that implementation of the CRD IG should be required first, followed by the DTR and PAS IGs. Several commenters identified the DTR IG as likely to include the most novel implementation challenges. Response: We appreciate commenters recommendations regarding the sequencing and phased availability of Health IT Modules certified to electronic prior authorization workflows. We agree that the workflow envisioned in the CRD, DTR, and PAS IGs seeks to comprehensively address prior authorization processes, and that these IGs rely on advanced features such as CDS Hooks and Clinical Quality Language (CQL). We acknowledge tha DTR, and PAS IGs seeks to comprehensively address prior authorization processes, and that these IGs rely on advanced features such as CDS Hooks and Clinical Quality Language (CQL). We acknowledge that there may be potential benefits of a phased approach identified by commenters, for instance, beginning with implementation of the CRD and PAS IGs. This approach may allow health IT developers to focus more intensively on development of more advanced capabilities over a longer time period. We note that, as discussed in section IX.B.4.b.(6)(f) of this final rule, we are not finalizing our proposal to include the ‘‘prior authorization API—provider’’ criterion in 45 CFR 170.315(g)(34) in the Base EHR definition by a certain date. We are also not finalizing to include criteria in 45 CFR 170.315(g)(31)–(33) in the Base EHR definition. We are, therefore, not defining a specific date by which these criteria must be certified and provided to customers. Instead, developers may begin certification as soon as testing is available after the effective date of this final rule and work with their customers to implement in the manner most appropriate for their needs. However, we note that requirement as soon as testing is available after the effective date of this final rule and work with their customers to implement in the manner most appropriate for their needs. However, we note that requirements in other HHS, federal, state or local VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00634 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37169 programs for adoption and use of health IT certified to ONC health IT certification criteria may include dates impacting health IT developers’ ability to sequence the rollout of certified health IT functionality to customers. For instance, developer timelines may be impacted by requirements to use technology certified to the finalized criteria for reporting of the Electronic Prior Authorization measures finalized for inclusion in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category beginning with the EHR reporting period in CY 2027 and CY 2027 performance period/2029 MIPS payment year, respectively (89 FR 8926). We believe our ap S Promoting Interoperability performance category beginning with the EHR reporting period in CY 2027 and CY 2027 performance period/2029 MIPS payment year, respectively (89 FR 8926). We believe our approach of supporting certification as soon as possible after the effective date of the rule—without inclusion of a compliance timeline through the Base EHR definition—will allow for a transition period with implementation testing while also supporting timelines for use under other HHS programs. After consideration of the public comments, we are finalizing an alternative structure for certification criteria for electronic prior authorization. Specifically, we are finalizing separate criteria in 45 CFR 170.315(g)(31), (g)(32), and (g)(33) to support the CRD, DTR, and PAS IGs, respectively, rather than finalizing a single criterion at 45 CFR 170.315(g)(34), as proposed. Finalizing separate certification criteria aligned with the capabilities described in each IG will support a more dynamic health IT marketplace by allowing Health IT Modules to demonstrate conformance to the three required IGs individually, in combination, or as a group. A more detailed discussion of how we are finalizing alth IT marketplace by allowing Health IT Modules to demonstrate conformance to the three required IGs individually, in combination, or as a group. A more detailed discussion of how we are finalizing the proposals in 45 CFR 170.315(g)(34) as part of certification criteria in 45 CFR 170.315(g)(31) through (33) is provided below. As noted previously, we are finalizing the same versions of the IGs to support the criteria in 45 CFR 170.315(g)(31) through (33) as we identified in the HTI–2 Proposed Rule, with the important proviso that these standards are eligible for SVAP, thus enabling developers to certify Health IT Modules to these criteria using newer versions of these adopted standards. (iii) Coverage Requirements Discovery In the HTI–2 Proposed Rule, we proposed in 45 CFR 170.315(g)(34)(i) that the ‘‘prior authorization API— provider’’ certification criterion must support capabilities related to coverage discovery (89 FR 63588). We noted that these proposals were intended to facilitate the automation of both information exchange and prior authorization and reduce the need for provider-end manual intervention. We stated that Health IT Modules certified to this certification criter te the automation of both information exchange and prior authorization and reduce the need for provider-end manual intervention. We stated that Health IT Modules certified to this certification criterion would be able to request coverage information from a payer, for instance when a future encounter is being scheduled for a patient, and to initiate prior authorization electronically when a treatment decision has been made. We stated that these requirements would ensure that providers can request and receive a wide variety of information including updates to coverage information, alternative services or products, documentation requirements and rules related to coverage, forms, and templates to complete, and indications of whether prior authorization is required. In 45 CFR 170.315(g)(34)(i), we proposed that a Health IT Module certified to the criterion must support capabilities to initiate and exchange information with payer systems as a client to support the identification of coverage requirements (89 FR 63588 and 63589). In 45 CFR 170.315(g)(34)(i)(A) we proposed that the Health IT Module must support the requirements described in the ‘‘Privacy, Security, and Safety’’ section of a requirements (89 FR 63588 and 63589). In 45 CFR 170.315(g)(34)(i)(A) we proposed that the Health IT Module must support the requirements described in the ‘‘Privacy, Security, and Safety’’ section of at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(1) (where we proposed to adopt the CRD IG version 2.0.1—STU 2). In 45 CFR 170.315(g)(34)(i)(B), we proposed that the Health IT Module must support capabilities in 45 CFR 170.315(j)(20) (where we proposed to adopt the ‘‘workflow triggers for decision support interventions’’ certification criterion) to enable workflow triggers to call decision support services, including support for ‘‘appointment-book,’’ ‘‘encounter-start,’’ ‘‘encounter-discharge,’’ ‘‘order- dispatch,’’ ‘‘order-select,’’ and ‘‘order- sign’’ CDS Hooks, according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(1) and requirements in 45 CFR 170.315(j)(20). In 45 CFR 170.315(g)(34)(i)(C), we proposed that the Health IT Module must support the requirements applicable to ‘‘CRD Clients’’ in at least one of the versions of the implementation specification in 45 CFR 170.215(j)(1) including, we proposed that the Health IT Module must support the requirements applicable to ‘‘CRD Clients’’ in at least one of the versions of the implementation specification in 45 CFR 170.215(j)(1) including, as proposed in 45 CFR 170.315(g)(34)(i)(C)(1), the requirements in the ‘‘CRD Client CapabilityStatement,’’ and, as proposed in 45 CFR 170.315(g)(34)(i)(C)(2), support for the ‘‘SHOULD’’ requirements applicable to ‘‘CRD Clients’’ in Section 5.8 ‘‘Additional Data Retrieval.’’ We requested public input on whether to instead finalize a policy that these ‘‘SHOULD’’ requirements should be treated as ‘‘SHALL’’ requirements. The following is a summary of the comments we received and our responses: Comment: Several commenters offered general support for our requirements for the use of the CRD IG as the basis for the criterion elements in 45 CFR 170.315(g)(34)(i). Commenters noted that feedback from early implementations of the CRD IG have shown that the functionality reflected in the IG can provide substantial value in facilitating prior authorization workflows. Response: We thank commenters for their support for our proposal to require support for the CRD IG. Comment: Several commenters suppo e substantial value in facilitating prior authorization workflows. Response: We thank commenters for their support for our proposal to require support for the CRD IG. Comment: Several commenters supported our proposal in 45 CFR 170.315(g)(34)(i)(C)(2) to require support for ‘‘SHOULD’’ requirements applicable to Coverage Requirements Discovery (CRD) Clients for additional data retrieval. These commenters stated that implementing a pre-fetch query functionality is critical for a CDS server to fully determine coverage requirements and reduce the need for manual intervention by clinicians. Response: We thank commenters for their support. Comment: Other commenters expressed concerns with our proposal to require support for ‘‘SHOULD’’ requirements applicable to CRD clients for additional data retrieval, and our discussion of treating these requirements as ‘‘SHALL’’ requirements. Commenters stated that the IG includes several ambiguous requirements, such as automatic parsing of clinical decision support (CDS) discovery endpoints and limited coverages returned in search based on payer client, and recommended that additional development time should be provided in order to resolve these ambi ion support (CDS) discovery endpoints and limited coverages returned in search based on payer client, and recommended that additional development time should be provided in order to resolve these ambiguities. Another commenter recommended that, while developers may choose to include such functionality in Health IT Modules, ASTP/ONC should not require implementation of these requirements for certification. Response: We appreciate the comments regarding our proposal in 45 CFR 170.315(g)(34)(i)(C)(2) to require the ‘‘SHOULD’’ requirements applicable to ‘‘CRD Clients’’ in the ‘‘Additional Data Retrieval’’ section of the CRD IG. While we believe these capabilities may result in a more efficient and timely CRD workflow for users, we acknowledge and agree with the feedback that these requirements are currently optional in VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00635 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37170 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations the CRD IG and may not currently provide sufficient technical detail needed for implementation. As a r a h k 37170 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations the CRD IG and may not currently provide sufficient technical detail needed for implementation. As a result, we are not finalizing this proposed requirement. However, we encourage developers to consider implementation of these capabilities and encourage the standards community to continue to iterate upon and refine these capabilities in future versions of the CRD IG. Comment: Regarding our proposal that a Health IT Module certified to the ‘‘prior authorization API—provider’’ support the six different hooks identified in the proposed rule, several commenters recommended that ASTP/ ONC provide additional flexibility regarding what hooks developers are required to support. Commenters stated that the proposed requirements represented demands on Health IT Modules over and above the requirements in the IGs and recommended ASTP/ONC consider focusing on an initial core set of hooks that can expand over time as workflows develop. Response: We thank commenters for their feedback on our proposal in 45 CFR 170.315(g)(34)(i)(B) to require support for the ‘‘appointment-book’’, ‘‘encounter-start’’, ‘ over time as workflows develop. Response: We thank commenters for their feedback on our proposal in 45 CFR 170.315(g)(34)(i)(B) to require support for the ‘‘appointment-book’’, ‘‘encounter-start’’, ‘‘encounter- discharge’’, ‘‘order-dispatch’’, ‘‘order- select,’’ and ‘‘order-sign’’ CDS Hooks. We appreciate commenter feedback requesting additional flexibility regarding the proposed requirements, particularly that not all Health IT Modules would be used in the workflows corresponding to the proposed CDS Hooks. Furthermore, we agree with commenters’ recommendation to focus on a smaller set of hooks for initial implementation. We also acknowledge that many of the proposed CDS Hooks are indicated by the CDS Hooks IG as low maturity. We believe requiring only the ‘‘order-sign’’ CDS Hook will provide a relatively mature and impactful CDS Hook for initial baseline criterion requirements for provider systems. The ‘‘order-sign’’ CDS Hook is one of the ‘‘primary hooks’’ of the CRD IG and, according to the CDS Hooks IG, the most mature of the six CDS Hooks proposed. We encourage industry to explore opportunities to implement other CDS Hooks to reduce provider burden. Comment: Several commenter ng to the CDS Hooks IG, the most mature of the six CDS Hooks proposed. We encourage industry to explore opportunities to implement other CDS Hooks to reduce provider burden. Comment: Several commenters noted that implementers are currently evaluating if a regular FHIR operation or a CDS hook could best execute the actions identified under the CRD IG. These commenters stated that if developers are required to certify Health IT Modules to CDS Hooks, opportunities for innovation and iteration on the IGs may be slowed, which are important given the evolving nature of the IG. Other commenters stated that they did not see a compelling need to require CDS Hooks as the only mechanism to invoke a payer service. Instead, the commenters recommended that ASTP/ ONC define an operation definition that MAY be supported and only finalize requirements for the use of CDS Hooks as ‘‘SHOULD’’ requirements. Response: We appreciate commenters’ recommendations. We note that CDS Hooks is a central component within the CRD IG workflow, and we believe it is an important and extensible functionality for industry to pursue. We do not agree that requiring CDS Hooks will slow innovation on the IG; rather, the w ithin the CRD IG workflow, and we believe it is an important and extensible functionality for industry to pursue. We do not agree that requiring CDS Hooks will slow innovation on the IG; rather, the widespread use and deployment of CDS Hooks will result in more robust interoperability and dynamic information workflows to send and receive data in support of electronic prior authorization, among many other potential use cases. Where there may be opportunities to improve the CDS Hooks IG, such widespread deployment will allow for more rapid revision and improvement of the IG. While we are aware of alternatives to CDS Hooks to invoke a payer service, we note that only the CDS Hooks IG is cross- referenced in the CRD IG for this purpose. Thus, we are finalizing only the use of the CDS Hooks IG for this purpose to be consistent with the CRD IG. Also, we are finalizing a limited scope of ‘‘SHOULD’’ requirements with specific support requirements in 45 CFR 170.315(g)(31)(i)(B) to call decision support services including support for the ‘‘order-sign’’ CDS Hook. Comment: Commenters noted that the triggers included in the CRD IG capability statement assume that an encounter has occurred. Howe support services including support for the ‘‘order-sign’’ CDS Hook. Comment: Commenters noted that the triggers included in the CRD IG capability statement assume that an encounter has occurred. However, there are numerous scenarios in which the prior authorization workflow may be initiated in the absence of a patient encounter. Commenters recommended that ATSP/ONC finalize an expanded set of trigger events including those that are not dependent upon a patient encounter. Response: We thank commenters for their input, but we decline to articulate a list of triggers necessary to initiate a prior authorization workflow at this time. We expect implementers to work with standards developers to refine aspects of the CRD IG, leveraging real- world experience, to achieve more consistent and effective implementation of coverage requirements discovery workflows. These refinements may include expanding the scenarios under which a prior authorization workflow must be initiated. After consideration of the public comments, we are finalizing the proposed requirements in 45 CFR 170.315(g)(34)(i) as part of the ‘‘provider prior authorization API— coverage requirements discovery’’ certification cri n of the public comments, we are finalizing the proposed requirements in 45 CFR 170.315(g)(34)(i) as part of the ‘‘provider prior authorization API— coverage requirements discovery’’ certification criterion in 45 CFR 170.315(g)(31), with modifications. We describe how the proposed requirements map to the requirements we are finalizing below. In general, we are finalizing technical requirements in 45 CFR 170.315(g)(31)(i) to require the capabilities associated with the ‘‘CRD Client’’ system actor defined in the CRD IG to enable users to request and receive coverage requirements. The regulation text we are finalizing in 45 CFR 170.315(g)(31) reorganizes, rephrases, and reduces the scope of the requirements proposed in 45 CFR 170.315(g)(34)(i). We proposed to require in 45 CFR 170.315(g)(34)(i)(B) and 45 CFR 170.315(g)(34)(i)(B)(1) to require support for the capabilities in 45 CFR 170.315(j)(20) to enable workflow triggers to call decision support services, including support for ‘‘appointment-book’’, ‘‘encounter-start’’, ‘‘encounter-discharge’’, ‘‘order- dispatch’’, ‘‘order-select,’’ and ‘‘order- sign’’ CDS Hooks, according to at least one of the versions of the implementation specifi ment-book’’, ‘‘encounter-start’’, ‘‘encounter-discharge’’, ‘‘order- dispatch’’, ‘‘order-select,’’ and ‘‘order- sign’’ CDS Hooks, according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(1) and requirements in 45 CFR 170.315(j)(20) of this section. We are finalizing with modification these requirements in 45 CFR 170.315(g)(31)(i)(B) to enable workflow triggers to call decision support services, to streamline the text, and limit the required CDS Hooks to only ‘‘order-sign.’’ We proposed in 45 CFR 170.315(g)(34)(i)(C) and 45 CFR 170.315(g)(34)(i)(C)(1) and (2) to require support for the requirements applicable to ‘‘CRD Clients’’ in at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(1), including the requirements in the ‘‘CRD Client CapabilityStatement’’ and the ‘‘SHOULD’’ requirements applicable to ‘‘CRD Clients’’ in Section 5.8 ‘‘Additional Data Retrieval.’’ We are finalizing requirements in 45 CFR 170.315(g)(31)(i)(C) to support all requirements and capabilities applicable to a ‘‘CRD Client,’’ with modification to combine and rephrase the proposed paragraphs of 45 CFR 170.315(g)(34)(i)(C) an FR 170.315(g)(31)(i)(C) to support all requirements and capabilities applicable to a ‘‘CRD Client,’’ with modification to combine and rephrase the proposed paragraphs of 45 CFR 170.315(g)(34)(i)(C) and 45 CFR 170.315(g)(34)(i)(C)(1) for more streamlined text and clarity. While not explicitly stated in the paragraph we are finalizing at 45 CFR 170.315(g)(31)(i)(C), Health IT Modules will be required to VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00636 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37171 support the ‘‘CRD Client CapabilityStatement’’ as part of supporting all required capabilities applicable to ‘‘CRD Clients,’’ according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(1) (where we are adopting the CRD IG version 2.0.1—STU 2). We are not finalizing proposals at 45 CFR 170.315(g)(34)(i)(C)(2) for reasons discussed in our response to comments. We are finalizing 45 CFR 170.315(g)(31)(i)(A) to clarify required support for registration capabilities applicable at 45 CFR 170.315(g)(34)(i)(C)(2) for reasons discussed in our response to comments. We are finalizing 45 CFR 170.315(g)(31)(i)(A) to clarify required support for registration capabilities applicable to ‘‘CRD Clients.’’ This subparagraph clarifies a requirement proposed at 45 CFR 170.315(g)(34)(i)(C) for ‘‘CRD Clients’’ that is stated in the CRD IG but was not explicitly identified in the regulation text proposed at 45 CFR 170.315(g)(34). We note that a ‘‘CRD Client’’ must register with a ‘‘CDS Service’’ as a prerequisite to enable other required ‘‘CRD Client’’ FHIR API data capabilities. Registration requirements are described in the CDS Hooks and CRD IGs, thus we are finalizing the requirement in 45 CFR 170.315(g)(31)(i)(A) to remove potential ambiguity regarding required support for these critical capabilities in the Certification Program. We clarify that for the purposes of this requirement, ‘‘registration’’ includes registration and configuration necessary to exchange data for the purposes of coverage requirements discovery using workflows in accordance with CDS Hooks and CRD IGs we are finalizing at 45 CFR 170.215(f) and 45 CFR 170.215(j), respectively. See the section ‘‘Secu purposes of coverage requirements discovery using workflows in accordance with CDS Hooks and CRD IGs we are finalizing at 45 CFR 170.215(f) and 45 CFR 170.215(j), respectively. See the section ‘‘Security and Safety’’ in the CDS Hooks IG 477 and the section ‘‘Enabling a CRD Server’’ in the CRD IG 478 for additional details about the registration processes described in those IGs. We are also finalizing a paragraph for documentation requirements for the ‘‘provider prior authorization API— coverage requirements discovery’’ criterion in 45 CFR 170.315(g)(31)(ii), which states that supported API server capabilities of ‘‘CRD Clients’’ from the CRD IG must include complete accompanying technical documentation. The requirements we are finalizing are based on the documentation requirements we proposed in the HTI– 2 Proposed Rule at 45 CFR 170.404(a)(2)(i) and its subparagraphs (89 FR 63592 through 89 FR 63593). 477 See https://cds-hooks.hl7.org/#security-and- safety. 478 See https://hl7.org/fhir/us/davinci-crd/STU2/ foundation.html#enabling-a-crd-server. In the HTI–2 Proposed Rule, we proposed to include additional documentation requirements in 45 CFR 170.404(a)(2)(i) and proposed that prov r/us/davinci-crd/STU2/ foundation.html#enabling-a-crd-server. In the HTI–2 Proposed Rule, we proposed to include additional documentation requirements in 45 CFR 170.404(a)(2)(i) and proposed that provisions of the API Condition and Maintenance of Certification requirements at 45 CFR 170.404, including the proposed documentation requirements in 45 CFR 170.404(a)(2)(i), would be applicable to the proposed ‘‘prior authorization API—provider’’ criterion in 45 CFR 170.315(g)(34) (89 FR 63592 through 63593). However, we proposed the documentation requirements in 45 CFR 170.404(a)(2)(i) in tandem with proposals to remove similar language around documentation requirements from the ‘‘standardized API for patient and population services’’ criterion in 45 CFR 170.315(g)(10). Under the narrow scope of this final rule, we are not finalizing any proposals in 45 CFR 170.315(g)(10), and therefore we are not finalizing the related documentation requirements in 45 CFR 170.404(a)(2)(i). Instead, we are finalizing references to ‘‘complete accompanying technical documentation’’ as part of the criteria in 45 CFR 170.315(g)(31)(ii) and 45 CFR 170.315(g)(33)(ii). For the purposes of the requirement in 45 inalizing references to ‘‘complete accompanying technical documentation’’ as part of the criteria in 45 CFR 170.315(g)(31)(ii) and 45 CFR 170.315(g)(33)(ii). For the purposes of the requirement in 45 CFR 170.315(g)(31)(ii), we clarify that the following is expected to be included as part of complete accompanying technical documentation as applicable: (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/ structures, exceptions and exception handling methods and their returns; (2) the software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and (3) all applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module’s authorization server. The expectation for technical documentation is consistent with what is currently required at 45 CFR 170.315(g)(10)(viii). Pursuant to the API Condition and Maintenance of Certification requirements at 45 CFR 170.404, which we are finalizing to apply to the ‘‘provider prior authorization API—covera R 170.315(g)(10)(viii). Pursuant to the API Condition and Maintenance of Certification requirements at 45 CFR 170.404, which we are finalizing to apply to the ‘‘provider prior authorization API—coverage requirements discovery’’ criterion in section XI.B.4.b.(6)(c) of this final rule, the complete accompanying technical documentation required by 45 CFR 170.315(g)(31)(ii) must be publicly published as part of the Certified API Developer’s complete business and technical documentation. We discuss revisions to 45 CFR 170.404 with implications for certified health IT developers that have Health IT Modules certified to 45 CFR 170.315(g)(31), (g)(32), and (g)(33) in section XI.B.4.b.(6)(d) of this final rule. (iv) Documentation Templates and Rules In 45 CFR 170.315(g)(34)(ii) we proposed requirements related to documentation and rules exchange (89 FR 63589). The DaVinci DTR and CRD IGs utilize Clinical Quality Language (CQL) to allow payers to inspect a patient’s record for the necessary information related to the required documentation for a proposed item (such as durable medical equipment), medication, procedure, or other service. The DTR IG details the use of a payer provided Questionn rmation related to the required documentation for a proposed item (such as durable medical equipment), medication, procedure, or other service. The DTR IG details the use of a payer provided Questionnaire resource and results from CQL execution to generate a QuestionnaireResponse resource containing the necessary information. We noted that this IG can allow payer APIs to specify how rules may be executed in a provider context so that documentation requirements are met, while at the same time reducing provider burden by reducing manual data entry. We proposed in 45 CFR 170.315(g)(34)(ii) that a Health IT Module certified to the ‘‘prior authorization API—provider’’ certification criterion must support the ability to request and populate prior authorization documentation templates and rules from payer systems according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1—STU 2). We noted at 89 FR 63589 that ‘‘Light’’ DTR capabilities are applicable to EHRs that rely on a SMART on FHIR application to handle the form filling function of DTR. This requires the server to provide access to t 89 FR 63589 that ‘‘Light’’ DTR capabilities are applicable to EHRs that rely on a SMART on FHIR application to handle the form filling function of DTR. This requires the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources. In 45 CFR 170.315(g)(34)(ii)(A)(1), we proposed the Health IT Module must support the capabilities included in the ‘‘Light DTR EHR’’ CapabilityStatement according to at least one versions of the implementation specification adopted in 45 CFR 170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1—STU 2). In 45 CFR 170.315(g)(34)(ii)(A)(2)(i), we proposed that the Health IT Module must support functional registration of the ‘‘DTR SMART Client’’ according to the requirements included in 45 CFR 170.315(j)(1) (where we proposed to VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00637 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37172 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations adopt a ‘‘functional registration’’ criterion). We also proposed in 45 CFR S 7 W 9 K S D n o d n o m m a h k 37172 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations adopt a ‘‘functional registration’’ criterion). We also proposed in 45 CFR 170.315(g)(34)(ii)(A)(2)(ii) that the Health IT Module must support dynamic registration of the ‘‘DTR SMART Client’’ according to the requirements included in 45 CFR 170.315(j)(2) (where we proposed to adopt a certification criterion for ‘‘dynamic registration’’). In 45 CFR 170.315(g)(34)(ii)(A)(3), we proposed that the Health IT Module must support launching the ‘‘DTR SMART Client’’ according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1—STU 2) to allow providers to launch an app to complete documentation for prior authorization according to at least one of the versions of the implementation specification in 45 CFR 170.215(j)(2). In 45 CFR 170.315(g)(34)(ii)(A)(3)(i) we proposed that the Health IT Module must support authentication and authorization during the process of granting access to patient data to users according to the requirements in 45 CFR 170.315(j)(10) (where we pro t the Health IT Module must support authentication and authorization during the process of granting access to patient data to users according to the requirements in 45 CFR 170.315(j)(10) (where we proposed to adopt a certification criterion for ‘‘SMART clinician access for EHR launch’’). In 45 CFR 170.315(g)(34)(ii)(A)(3)(ii) we proposed that the Health IT Module must support asymmetric certificate- based authentication according to the requirements in 45 CFR 170.315(j)(11) for the ‘‘Light DTR Client’’ dynamically registered using the capabilities in 45 CFR 170.315(g)(34)(ii)(A)(2)(ii). We stated that in contrast to ‘‘Light DTR EHR’’ capabilities, ‘‘full’’ DTR capabilities are relevant to EHRs that manage the form filling functions of DTR internally. In 45 CFR 170.315(g)(34)(ii)(B), we proposed that the Health IT Module must support the capabilities included in the ‘‘Full DTR EHR’’ CapabilityStatement according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1—STU 2). Such EHRs need only support client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question in 45 CFR 170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1—STU 2). Such EHRs need only support client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations. We requested comments on our proposals. The following is a summary of the comments we received and our responses: Comment: We received numerous comments on our proposal in 45 CFR 170.315(g)(34)(ii) to require Health IT Modules certified to the ‘‘prior authorization API—provider’’ certification criterion to support both the capabilities included in the ‘‘Light DTR EHR’’ CapabilityStatement and the ‘‘Full DTR EHR’’ CapabilityStatement. Some commenters supported our proposal to finalize both requirements, stating that requiring all EHRs to comply with both sets of requirements will ensure market readiness, as some payers may not be ready to support the ‘‘full’’ DTR requirements initially and may need to rely upon a DTR SMART App in an EHR or practice management system to support implementation. Other commenters recommended that ASTP/ONC should allow developers to choose whether to support either the ‘‘light’’ or ‘‘full’’ DTR requirements, stating that a requirement to support mplementation. Other commenters recommended that ASTP/ONC should allow developers to choose whether to support either the ‘‘light’’ or ‘‘full’’ DTR requirements, stating that a requirement to support both would be duplicative. Finally, numerous commenters recommended that ASTP/ONC, if it finalizes the criterion, should only require support for the ‘‘full’’ DTR capabilities. Commenters stated that the ‘‘full’’ DTR functionality has more potential for automation and improved performance, whereas implementation of ‘‘light’’ capabilities, while providing a faster path to adoption, may result in an inconsistent end-user experience. By contrast, commenters believed that requiring developers to implement the ‘‘full’’ DTR process would result in a superior user experience for clinicians and availability of the complete suite of functions including the ability to automate the completing of clinical templates. Moreover, commenters stated that the ‘‘light’’ functionality would not provide all of the information needed by payers and would not provide value to clinicians. Availability of the ‘‘full’’ DTR functionality would ultimately encourage increased adoption of prior authorization APIs. Re the information needed by payers and would not provide value to clinicians. Availability of the ‘‘full’’ DTR functionality would ultimately encourage increased adoption of prior authorization APIs. Response: We thank commenters for their feedback on our proposal to require support for both ‘‘Full DTR EHR’’ and ‘‘Light DTR EHR’’ capabilities in the proposed ‘‘prior authorization API—provider’’ criterion. We agree with commenters that requiring support for ‘‘Full DTR EHR’’ capabilities would require certified API technology to support DTR capabilities that can reduce prior authorization burden through payer questionnaire retrieval and population. We also agree with commenters that ‘‘Light DTR EHR’’ capabilities alone would not result in substantial reduction of prior authorization burden and that requiring both ‘‘Light DTR EHR’’ and ‘‘Full DTR EHR’’ support simultaneously could burden developers with supporting a duplicative DTR workflow. Thus, we believe requiring support for the ‘‘Full DTR EHR’’ promotes industry adoption of substantial burden reduction capabilities from the DTR IG while also giving developers implementation flexibility. We note that under the ‘‘Full DTR EHR’’ requ DTR EHR’’ promotes industry adoption of substantial burden reduction capabilities from the DTR IG while also giving developers implementation flexibility. We note that under the ‘‘Full DTR EHR’’ requirements, health IT developers could develop the required DTR capabilities themselves or choose to integrate DTR apps with such capabilities into their Health IT Modules. For purposes of certification to DTR requirements, DTR apps could be integrated into certified health IT as ‘‘relied upon software,’’ which is permitted to be used by health IT developers to demonstrate compliance with certification criteria requirements. After consideration of the public comment, we are finalizing the proposed requirements in 45 CFR 170.315(g)(34)(ii) as part of the ‘‘provider prior authorization API— documentation templates and rules’’ certification criterion in 45 CFR 170.315(g)(32), with modifications. Specifically, we are finalizing in 45 CFR 170.315(g)(32) that certified Health IT Modules must support all requirements and required capabilities applicable to a ‘‘Full DTR EHR’’ according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(2) (where we a rt all requirements and required capabilities applicable to a ‘‘Full DTR EHR’’ according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(2) (where we are adopting the DTR IG version 2.0.1—STU 2). We are not finalizing proposed requirements to support capabilities specific to a ‘‘Light DTR EHR.’’ As part of finalizing our proposal to require support for the capabilities included in the ‘‘Full DTR EHR’’ CapabilityStatement under the ‘‘provider prior authorization API— documentation templates and rules’’ criterion in 45 CFR 170.315(g)(32), we have made additional modifications to the language proposed in 45 CFR 170.315(g)(34)(ii). We are finalizing three separate paragraphs at 45 CFR 170.315(g)(32)(i)–(iii) to clarify and refine the requirements we initially proposed. The paragraph we are finalizing in 45 CFR 170.315(g)(32)(iii) includes similar language to proposed 45 CFR 170.315(g)(34)(ii)(B) and requires support for all requirements and required capabilities applicable to a ‘‘Full DTR EHR.’’ This revised version of the proposed language provides clarity by rephrasing the requirement using plain language while maintaining the same sco required capabilities applicable to a ‘‘Full DTR EHR.’’ This revised version of the proposed language provides clarity by rephrasing the requirement using plain language while maintaining the same scope. We note that while the ‘‘Full DTR EHR’’ CapabilityStatement artifact is not specifically referenced in the requirement language we are finalizing, health IT developers must support the capabilities required by the ‘‘Full DTR EHR’’ CapabilityStatement. Specifically, the requirement to support all requirements and required capabilities applicable to a ‘‘Full DTR VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00638 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37173 EHR’’ would also include support for the ‘‘Full DTR EHR’’ CapabilityStatement artifact. We also reiterate general Certification Program policy that all applicable conformance requirements expressed by a standard or implementation guide referenced in certification criteria are required to be supported for the purposes of certification unless otherwise specified conformance requirements expressed by a standard or implementation guide referenced in certification criteria are required to be supported for the purposes of certification unless otherwise specified. For example, for the 45 CFR 170.315(g)(32) criterion, all ‘‘SHALL’’ and ‘‘Must Support’’ requirements applicable to the ‘‘Full DTR EHR’’ system actor are required to be supported for the purposes of certification. The paragraph we are finalizing in 45 CFR 170.315(g)(32)(i) specifies required support for registration capabilities applicable to a ‘‘Full DTR EHR.’’ This language clarifies a component of the requirement proposed at 45 CFR 170.315(g)(34)(ii)(B) that is included as part of support for requirements applicable to a ‘‘Full DTR EHR’’ in the DTR IG. Specifically, a ‘‘Full DTR EHR’’ must register with a ‘‘DTR Payer Service’’ as a prerequisite necessary to enable other required ‘‘Full DTR EHR’’ FHIR API data capabilities. Registration requirements for a ‘‘Full DTR EHR’’ are specified in the DTR IG, and we are finalizing requirements in 45 CFR 170.315(g)(32)(iii) to remove ambiguity that such registration requirements must be supported. See section ‘‘Configuring App/EHR to Payer C in the DTR IG, and we are finalizing requirements in 45 CFR 170.315(g)(32)(iii) to remove ambiguity that such registration requirements must be supported. See section ‘‘Configuring App/EHR to Payer Connectivity’’ in the DTR IG 479 for additional details about registration requirements for a ‘‘Full DTR EHR.’’ The paragraph we are finalizing in 45 CFR 170.315(g)(32)(ii) includes language to clarify a component of the requirement proposed at 45 CFR 170.315(g)(34)(ii)(B) to support requirements applicable to a ‘‘Full DTR EHR.’’ The paragraph at 45 CFR 170.315(g)(32)(ii) specifies required support for system authentication and authorization as a client in accordance with the ‘‘Backend Services’’ section of a version of the SMART App Launch IG adopted under 45 CFR 170.215(c). We include this language to clarify potential ambiguity in the DTR IG regarding ‘‘Full DTR EHR’’ requirements to support authentication and authorization in accordance with the SMART on FHIR Backend Services specification as well as to provide clarity and consistency to implementers regarding which versions of the SMART on FHIR Backend Services specification are available for the purposes of certification. The ‘‘Au ion as well as to provide clarity and consistency to implementers regarding which versions of the SMART on FHIR Backend Services specification are available for the purposes of certification. The ‘‘Authenticating DTR client to payer API’’ section of the DTR IG we are adopting in 45 CFR 170.215(j)(2) specifies the requirement for payers to require DTR EHRs to use SMART on FHIR Backend Services to authenticate to payer DTR API endpoints. As stated in the DTR IG in section ‘‘Authenticating DTR client to payer API,’’ 480 this requirement is framed to apply to the payer DTR API endpoint and does not require a specific version of the SMART on FHIR Backend Services specification. The language we are finalizing in 45 CFR 170.315(g)(32)(ii) clarify this element of the IG by (1) describing the effective requirement in the DTR IG explicitly, rather than implicitly through payer conformance requirements, to require the Health IT Module to support authentication and authorization according to SMART on FHIR Backend Services; and (2) requiring support for one of the versions of the SMART on FHIR Backend Services specification contained within the SMART App Launch implementation specifications ado on FHIR Backend Services; and (2) requiring support for one of the versions of the SMART on FHIR Backend Services specification contained within the SMART App Launch implementation specifications adopted at 45 CFR 170.215(c). (v) Prior Authorization Support Finally, in 45 CFR 170.315(g)(34)(iii) we proposed that the ‘‘prior authorization API—provider’’ certification criterion must support capabilities related to the submission of a prior authorization request (89 FR 63588). For the ‘‘prior authorization API— provider’’ certification criterion, we proposed in 45 CFR 170.315(g)(34)(iii)(A) that the Health IT Module must support the ability to submit a prior authorization request to a payer system according to at least one of the versions of the implementation specification adopted in 170.215(j)(3) (where we proposed to adopt the PAS IG version 2.0.1—STU 2). Specifically, we proposed in 45 CFR 170.315(g)(34)(iii)(A)(1) that the Health IT Module include support for the ‘‘EHR PAS Capabilities’’ CapabilityStatement according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(3). We proposed in 45 CFR 170.315(g)(34)(iii)(A)(2) that the Health ies’’ CapabilityStatement according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(3). We proposed in 45 CFR 170.315(g)(34)(iii)(A)(2) that the Health IT Module support the ability to include documentation created in 45 CFR 170.315(g)(34)(ii) in a prior authorization request to a payer system according to at least one of the versions 479 https://hl7.org/fhir/us/davinci-dtr/STU2/ specification.html#configuring-appehr-to-payer- connectivity. 480 https://hl7.org/fhir/us/davinci-dtr/STU2/ specification.html#authenticating-dtr-client-to- payer-api. of the implementation specification adopted in 45 CFR 170.215(j)(3). We proposed in 45 CFR 170.315(g)(34)(iii)(A)(3) that the Health IT Module support the ability to consume and process a ‘‘ClaimResponse’’ according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(3). Finally, we proposed in 45 CFR 170.315(g)(34)(iii)(A)(4) that the Health IT Module support subscriptions as a client according to the requirements in 45 CFR 170.315(j)(24) (where we proposed to adopt a ‘‘subscriptions— client’’ certification criterion) and an implementation specific support subscriptions as a client according to the requirements in 45 CFR 170.315(j)(24) (where we proposed to adopt a ‘‘subscriptions— client’’ certification criterion) and an implementation specification in 45 CFR 170.215(j)(3), in order to support ‘‘pended authorization responses.’’ Comment: Several commenters highlighted specific technical issues with the PAS IG which commenters have identified as part of ongoing development work on the IG. Response: We appreciate commenters’ highlighting of these issues. We note that several of these issues have been resolved since the publication of the HTI–2 Proposed Rule. We acknowledge that, as with the other Burden Reduction IGs we are adopting in this section, the PAS IG continues to evolve. We appreciate the continued collaboration of interested parties across the standards development community in improving these specifications and will seek to utilize flexibility under the Certification Program to ensure updated versions of the implementation specifications are available for use by health IT developers in a timely manner. After consideration of the public comments, we are finalizing the proposed requirements in 45 CFR 170.315(g)(34)(i tion specifications are available for use by health IT developers in a timely manner. After consideration of the public comments, we are finalizing the proposed requirements in 45 CFR 170.315(g)(34)(iii) as part of the ‘‘provider prior authorization API— prior authorization support’’ criterion in 45 CFR 170.315(g)(33), with modifications. The ‘‘provider prior authorization API—prior authorization support’’ criterion requires a Health IT Module to submit a prior authorization request as a client in accordance with at least one of the versions of the standard adopted in 45 CFR 170.215(j)(3) (where we are adopting the PAS IG version 2.0.1—STU 2). In comparison to proposed 45 CFR 170.315(g)(34)(iii) and its subparagraphs, the ‘‘provider prior authorization API—prior authorization support’’ criterion in 45 CFR 170.315(g)(33) has three categories of technical API requirements at and under 45 CFR 170.315(g)(33)(i). The paragraph we are finalizing in 45 CFR 170.315(g)(33)(i)(C) and its subparagraphs describe requirements to VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00639 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n graphs describe requirements to VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00639 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37174 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations support prior authorization transactions as a client and include similar language to proposed 45 CFR 170.315(g)(34)(iii)(A) and its subparagraphs, with the exception of the proposed ability in 45 CFR 170.315(g)(34)(iii)(A)(2) to include documentation created in 45 CFR 170.315(g)(34)(ii) in a prior authorization request to a payer system, according to at least one of the versions of the implementation specifications adopted in 45 CFR 170.215(j)(3). That proposed requirement would have required the Health IT Module to support including documentation created using DTR IG capabilities in a prior authorization request to a payer system according to the PAS IG. We are not finalizing this proposed requirement in the ‘‘provider prior authorization API—prior authorization support’’ criterion since we are finalizing DTR IG capabilities in a distinct criterion in 45 CFR 170.315(g)(32). We antici ed requirement in the ‘‘provider prior authorization API—prior authorization support’’ criterion since we are finalizing DTR IG capabilities in a distinct criterion in 45 CFR 170.315(g)(32). We anticipate that developers and implementers of certified health IT will combine capabilities of the CRD, DTR, and PAS IGs to reduce provider burden. This may occur because a certified health IT developer has chosen to certify to all three criteria at 45 CFR 170.315(g)(31) through (g)(33) or because a health IT developer with a Health IT Module certified to one or two of those criteria are working with other certified health IT developers’ Health IT Modules to complete the electronic prior authorization workflow. The paragraphs we are finalizing in 45 CFR 170.315(g)(33)(i)(A) and (B) specify required registration and authentication and authorization capabilities. Paragraph 45 CFR 170.315(g)(33)(i)(A) requires support for registration capabilities applicable to a client system and is a prerequisite capability required to enable authentication and authorization requirements we are finalizing in 45 CFR 170.315(g)(33)(i)(B). Paragraph 45 CFR 170.315(g)(33)(i)(B) requires system authentication and e capability required to enable authentication and authorization requirements we are finalizing in 45 CFR 170.315(g)(33)(i)(B). Paragraph 45 CFR 170.315(g)(33)(i)(B) requires system authentication and authorization as a client in accordance with the ‘‘Backend Services’’ section of at least one of the versions of the implementation specification adopted in 45 CFR 170.215(c). These paragraphs clarify components of the requirement we proposed in 45 CFR 170.315(g)(34)(iii)(A) to support the ability to submit a prior authorization request to a payer system according to at least one of the implementation specifications adopted in 45 CFR 170.215(j)(3) (where we are finalizing adoption of the PAS IG version 2.0.1— STU 2). The PAS IG requires in section ‘‘Privacy & Security’’ that the provider system supports authentication to the payer system or an intermediary, and recommends servers (e.g., payer systems) support the OAuth standard in a server to server capacity. While the PAS IG does not reference a specific version of the OAuth standard, the latest published version of the OAuth standard is OAuth 2.0 Authorization Framework (RFC 6749) 481 (OAuth 2.0) published October 2012. OAuth 2.0 is erence a specific version of the OAuth standard, the latest published version of the OAuth standard is OAuth 2.0 Authorization Framework (RFC 6749) 481 (OAuth 2.0) published October 2012. OAuth 2.0 is one of the foundational standards upon which the SMART Backend Services specification is based. Furthermore, the PAS IG requires all client (e.g., provider) systems comply with the ‘‘Security and Privacy’’ section of the Da Vinci Health Record Exchange (HRex) IG, without specifying a version of that IG. The ‘‘Security and Privacy’’ section of the latest published version of the Da Vinci HRex IG,482 published December 10, 2024, recommends OAuth server to server authentication as defined in the SMART Backend Services specification as one option when the identity of the requesting or receiving party is important. Of the options recommended by the Da Vinci HRex IG, we believe the SMART Backend Services specification aligns most closely with the authentication recommendation from the PAS IG and is a specification already widely supported in a server capacity by developers of certified health IT in accordance with the requirements in the 45 CFR 170.315(g)(10) ‘‘standardized API for patient d is a specification already widely supported in a server capacity by developers of certified health IT in accordance with the requirements in the 45 CFR 170.315(g)(10) ‘‘standardized API for patient and population services’’ criterion. We believe clarifying a requirement for this otherwise optional authentication specification is necessary to establish a consistent baseline authentication and authorization mechanism in the Certification Program for provider systems to authenticate with and receive authorization from payer systems when using prior authorization transaction capabilities from the PAS IG. We further note that according to our proposal in 45 CFR 170.315(g)(34)(ii)(B), Health IT Modules certified to 45 CFR 170.315(g)(34) would have been required to support the ‘‘Full DTR EHR’’ capabilities from the DTR IG (89 FR 63589 through 63590). As discussed in a previous comment response, supporting the SMART Backend Services specification as a client is part of implementing the ‘‘Full DTR EHR’’ capabilities from the DTR IG, and thus would have been required as part of the proposal at 45 CFR 170.315(g)(34)(ii)(B). Since we are finalizing DTR IG and PAS 481 https://datatracker.ietf l DTR EHR’’ capabilities from the DTR IG, and thus would have been required as part of the proposal at 45 CFR 170.315(g)(34)(ii)(B). Since we are finalizing DTR IG and PAS 481 https://datatracker.ietf.org/doc/html/rfc6749. 482 https://hl7.org/fhir/us/davinci-hrex/STU1.1/ security.html. IG capabilities from the 45 CFR 170.315(g)(34) proposal in distinct criteria at 45 CFR 170.315(g)(32) and (33) respectively, we finalize paragraphs 45 CFR 170.315(g)(32)(ii) and 45 CFR 170.315(g)(33)(i)(B) in those criteria to establish consistent requirements to support the SMART Backend Services specification as a client. In addition to the technical requirements we are finalizing at and under paragraph 45 CFR 170.315(g)(33)(i), we are also finalizing a paragraph for documentation requirements for the 45 CFR 170.315(g)(33) criterion in 45 CFR 170.315(g)(33)(ii). This paragraph requires that supported subscriptions client endpoint capabilities for the ‘‘REST-Hook’’ channel from the PAS IG must include complete accompanying technical documentation. These requirements complement existing requirements in the ‘‘Transparency conditions’’ at 45 CFR 170.404(a)(2) in lieu of finalizing the revisions to 45 C omplete accompanying technical documentation. These requirements complement existing requirements in the ‘‘Transparency conditions’’ at 45 CFR 170.404(a)(2) in lieu of finalizing the revisions to 45 CFR 170.404(a)(2)(i) and its subparagraphs that were proposed in the HTI–2 proposed rule. For the purposes of this requirement, we clarify that the following is expected to be included as part of complete accompanying technical documentation as applicable: (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/ structures, exceptions and exception handling methods and their returns; (2) the software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and (3) all applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module’s authorization server. Pursuant to the API Condition and Maintenance of Certification requirements at 45 CFR 170.404, the documentation required by 45 CFR 170.315(g)(33)(ii) must be publicly published as part of the Ce ver. Pursuant to the API Condition and Maintenance of Certification requirements at 45 CFR 170.404, the documentation required by 45 CFR 170.315(g)(33)(ii) must be publicly published as part of the Certified API Developer’s complete business and technical documentation. We discuss the finalization of including 45 CFR 170.315(g)(33) in the 45 CFR 170.404 API Condition and Maintenance of Certification requirements in section IX.B.4.b.(6)(d) of this final rule. In summary, after consideration of the public comment, we are finalizing the following three certification criteria based on the ‘‘prior authorization API— provider’’ criterion we proposed in in 45 CFR 170.315(g)(34): VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00640 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37175 • Provider prior authorization API— coverage requirements discovery (45 CFR 170.315(g)(31)). • Provider prior authorization API— documentation templates and rules (45 CFR 170.315(g)(32)). • Provider prior authorization API— prior authorization supp uirements discovery (45 CFR 170.315(g)(31)). • Provider prior authorization API— documentation templates and rules (45 CFR 170.315(g)(32)). • Provider prior authorization API— prior authorization support (45 CFR 170.315(g)(33)). These criteria include additional modifications to the proposals for the ‘‘prior authorization API—provider’’ criterion that we are finalizing in response to public comments, and in order to streamline and clarify requirements in the final criteria. We have discussed these modifications in detail above. (vi) Support for CMS Requirements In the HTI–2 Proposed Rule (89 FR 63591) we noted that the ‘‘prior authorization API—provider’’ certification criterion proposed in 45 CFR 170.315(g)(34), if finalized, would support the availability of certified health IT that can enable health care providers to interact with the Prior Authorization APIs established pursuant to CMS payer API requirements, using certified health IT. CMS also finalized Electronic Prior Authorization measures for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability Performance Category in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8926 ion measures for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability Performance Category in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8926). These measures are intended to incentivize eligible hospitals, CAHs, and eligible clinicians to use Prior Authorization APIs to submit their prior authorization requests (89 FR 8946). We stated that if we finalized our proposal for the ‘‘prior authorization API— provider’’ certification criterion, adopting and using technology certified to this criterion would enable MIPS eligible clinicians, eligible hospitals and CAHs to complete the prior authorization request actions associated with these measures using certified health IT. We also noted in the HTI–2 Proposed Rule that, at that time, CMS had not identified health IT certified to specific criteria to complete the actions specified for finalized Electronic Prior Authorization measures in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category (89 FR 63581 through 63582, 63591). We discussed how, if the proposed ‘‘prior authorization API—provider’’ certification criterion was fin and the MIPS Promoting Interoperability performance category (89 FR 63581 through 63582, 63591). We discussed how, if the proposed ‘‘prior authorization API—provider’’ certification criterion was finalized, we would work with CMS on appropriate steps within the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category to identify health IT certified to this criterion as an element of CEHRT necessary to report on the Electronic Prior Authorization measures. As CMS noted in the Interoperability and Prior Authorization Final Rule, use of health IT certified to support electronic prior authorization transactions can help to ensure that the actions associated with these measures are executed in a consistent fashion across the health care providers participating in these programs (89 FR 8926). Comment: Commenters stated that enabling providers to interact with APIs that payers are developing will be important for the uptake of these payer APIs and realizing the potential benefits of electronic prior authorization. Commenters also believed that the availability of health IT certified to the ‘‘prior authorization API—provider’’ criterion woul and realizing the potential benefits of electronic prior authorization. Commenters also believed that the availability of health IT certified to the ‘‘prior authorization API—provider’’ criterion would ensure that healthcare providers participating in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category will be able to meet requirements for reporting the Electronic Prior Authorization measures CMS has finalized. Response: We thank commenters for their support and will collaborate with CMS on steps to identify the criteria in 45 CFR 170.315(g)(31), (32), and (33) that we are finalizing in this rule as necessary to support reporting of the Electronic Prior Authorization measures finalized for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. Comment: Commenters expressed concerns about alignment between the Da Vinci CRD, DTR, and PAS IGs proposed for incorporation in the ‘‘prior authorization API—provider’’ criterion and the versions of the USCDI standard and US Core IG proposed for adoption in the HTI–2 Proposed Rule. Commenters stated that the proposed versions of the prior authorization API—provider’’ criterion and the versions of the USCDI standard and US Core IG proposed for adoption in the HTI–2 Proposed Rule. Commenters stated that the proposed versions of the Da Vinci IGs have not yet been updated to reference proposed versions of the USCDI standard and US Core IG, creating potential misalignment across requirements. Commenters also expressed concerns about the timeline for adoption of updated versions of these standards relative to deadlines that have been established by CMS for establishment of APIs meeting the requirements in the Interoperability and Prior Authorization final rule by impacted payers. Response: We appreciate commenters’ concerns regarding alignment of CRD, DTR, and PAS IGs with USCDI and US Core IG versions. We agree that there are degrees of misalignment between Version 2.0.1 of the CRD, DTR, and PAS IGs with the versions of USCDI and the US Core IG we proposed for adoption in the HTI–2 Proposed Rule. We note that we are not finalizing USCDI Version 4 and US Core IG Version 7 as part of this final rule. Thus, developers will not encounter potential misalignment if they certify to criteria we are finalizing in this rule t finalizing USCDI Version 4 and US Core IG Version 7 as part of this final rule. Thus, developers will not encounter potential misalignment if they certify to criteria we are finalizing in this rule that reference the Da Vinci standards using USCDI Version 3 and US Core IG 6.1. Further, we note that the 2.1.0 versions of the CRD, DTR, and PAS IGs have been updated to cover USCDI Version 4 and US Core IG Version 7. Taken together, this means that developers certifying Health IT Modules to certification criteria that reference these IGs may do so using USCDI Version 3 and US Core IG Version 6 or, by using SVAP, certify using subsequent versions of USCDI and US Core IG (up to Version 7, currently) and avoid misalignment. Regarding CMS requirements for payer APIs, as we are not finalizing USCDI Version 4 and US Core IG Version 7 in this final rule, payers would not be subject to challenges related to misalignment based upon these proposed versions at this time. We will continue to work closely with CMS to manage issues of alignment across adopted standards. Comment: We received numerous comments on issues related to CMS policies around prior authorization, including comments on the Pr osely with CMS to manage issues of alignment across adopted standards. Comment: We received numerous comments on issues related to CMS policies around prior authorization, including comments on the Prior Authorization API requirements finalized in the Interoperability and Prior Authorization final rule, and comments around other policies related to prior authorization that CMS could seek to advance as part of programs. Response: We value these recommendations and will ensure that these inputs are shared with CMS. We will work together with CMS to further explore opportunities to address these issues. (vii) Administrative Simplification Requirements Under HIPAA We noted that, pursuant to the administrative simplification rules established under HIPAA, the Secretary must adopt electronic standards for use by ‘‘covered entities,’’ which is defined as including health plans, healthcare clearinghouses, and certain healthcare providers.483 We noted that the two standards adopted for referral certification and authorization transactions under the HIPAA administrative simplification rules (45 CFR 162.1302) include: NCPDP Version 483 For more information, see https:// www.cms.gov/priorities certification and authorization transactions under the HIPAA administrative simplification rules (45 CFR 162.1302) include: NCPDP Version 483 For more information, see https:// www.cms.gov/priorities/key-initiatives/burden- reduction/administrative-simplification. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00641 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37176 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations D.0 for retail pharmacy drugs; and X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional request for review and response for items and services. HHS has also proposed to adopt the X12 275 standard, which is used to transmit additional documentation to support the exchange of the additional information that is required for prior authorization, in the ‘‘Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard’’ proposed rule (87 FR 78438). We stated that nothing in our proposed certificati nsactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard’’ proposed rule (87 FR 78438). We stated that nothing in our proposed certification criteria related to electronic prior authorization would alter requirements for covered entities to use adopted HIPAA transaction standards. Moreover, the FHIR specifications we proposed to adopt for these certification criteria would not conflict with the use of the adopted HIPAA standard, and we stated we would expect covered entities using technology certified to these criteria to ensure compliance with applicable requirements. We noted that in March 2021, the CMS National Standards Group (NSG), on behalf of HHS, approved an application 484 from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards for Da Vinci payers and their trading partners when using the FHIR standard for prior authorization. Under this exception, the group tested a prior authorization exchange using the HL7 FHIR Da Vinci standard without the X12 278 standard to determine whether this alternative standard for prior authorization could i eption, the group tested a prior authorization exchange using the HL7 FHIR Da Vinci standard without the X12 278 standard to determine whether this alternative standard for prior authorization could improve efficiency. HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the CMS HIPAA administrative simplification website.485 On February 28, 2024, CMS NSG, on behalf of HHS, announced an application of enforcement discretion for HIPAA covered entities that implement FHIR-based Prior Authorization APIs as described in the CMS Interoperability and Prior Authorization Final Rule (89 FR 484 See https://confluence.hl7.org/display/DVP/ Da+Vinci+HIPAA+Exception?preview=/113675673/ 113675685/Approval%20%232021031001.pdf. 485 Centers for Medicare & Medicaid Services (2022). Go-to-Guidance, Guidance Letters. Retrieved from https://www.cms.gov/priorities/key-initiatives/ burden-reduction/administrative-simplification/ subregulatory-guidance/letters. 8758).486 HHS stated that this action was in response to feedback received on multiple notices of proposed rulemaking and extensive stakeholder outreach and is intended to promote effi idance/letters. 8758).486 HHS stated that this action was in response to feedback received on multiple notices of proposed rulemaking and extensive stakeholder outreach and is intended to promote efficiency in the prior authorization process. Specifically, HHS stated that HIPAA Administrative Simplification enforcement action will not be taken against HIPAA covered entities that choose not to use the X12 278 standard as part of an electronic FHIR prior authorization process. We stated that HHS will continue to evaluate the HIPAA prior authorization transaction standards, including continuing to seek stakeholder input and evaluating the results of testing an all-FHIR-based transaction. We received numerous comments on our discussion of the intersection between our proposals and standards adopted by CMS for administrative simplification transactions. Comment: Several commenters raised concerns about the intersection between the proposed ‘‘prior authorization API— provider’’ criterion and the existing standards landscape for electronic prior authorization, which includes adoption and use of the X12 278 standard. Commenters stated that it is unclear how healthcare providers, if using H the existing standards landscape for electronic prior authorization, which includes adoption and use of the X12 278 standard. Commenters stated that it is unclear how healthcare providers, if using Health IT Modules certified to the proposed ‘‘prior authorization API— provider’’ criterion, would be able to interact with health plans that continue to use the X12 278 standard. A commenter cited the 2023 CAQH Index Report, noting that while industry adoption of the X12 278 is low at 31 percent, it has increased from 13 percent in 2019. Commenters stated that they expect there will be a significant length of time beyond the January 1, 2027, compliance date for impacted payers when healthcare providers will continue to use the X12 278 standard. Commenters expressed concerns that adoption of these certified Health IT Modules would create a bifurcated approach between the use of X12 and FHIR approaches to completing prior authorization requests, and that physician practices would need to contract with intermediaries in order to continue to use the X12 278 standard where necessary. Commenters believed that covered entities would effectively be prohibited from using the mandated X12 transa tract with intermediaries in order to continue to use the X12 278 standard where necessary. Commenters believed that covered entities would effectively be prohibited from using the mandated X12 transactions, particularly for the prior authorization submission step, and that under the proposals in the HTI–2 Proposed Rule and the final policies in the Interoperability and Prior 486 See https://www.cms.gov/files/document/ discretion-x12-278-enforcement-guidance-letter- remediated-2024-02-28.pdf. Authorization final rule, ASTP/ONC and CMS would create a scenario in which covered entities have no option to use the legally mandated transaction standard. Commenters further argued that this approach seems contrary to the Congressional mandate set out in the HIPAA electronic healthcare transactions. Commenters encouraged ASTP/ONC to work with CMS to clarify the use of X12 transactions within electronic prior authorization workflows. Response: We appreciate commenters’ concerns regarding the intersection of different HHS policies addressing standards for electronic prior authorization. We continue to work closely with CMS to address ongoing regulatory strategy around such standards. While ou ersection of different HHS policies addressing standards for electronic prior authorization. We continue to work closely with CMS to address ongoing regulatory strategy around such standards. While our finalization of certification criteria at 45 CFR 170.315(g)(31), (32), and (33) would support the availability of health IT enabling healthcare providers to conduct electronic prior authorization activities using the FHIR standards that we are adopting in this final rule, these final policies would not limit providers to exclusive use of technology using these standards for electronic prior authorization. Comment: Commenters acknowledged the availability of enforcement discretion issued by CMS as discussed in the proposed rule (89 FR 63591 through 63592) and stated their appreciation for this flexibility. However, commenters raised concerns that this enforcement discretion could be revoked at any time. Commenters also noted that the administrative simplification exception provided for use of Da Vinci standards has been completed but the findings from the exceptions process have not yet been made available to the public and suggested that this would be an important resource for the pu e of Da Vinci standards has been completed but the findings from the exceptions process have not yet been made available to the public and suggested that this would be an important resource for the public to be able to use when evaluating the proposed prior authorization approaches. Response: We acknowledge commenters’ concerns regarding reliance on CMS’ enforcement discretion. We believe this enforcement discretion provides significant flexibility to healthcare providers and payers to pursue innovative approaches to electronic prior authorization at the present time. However, we continue to support CMS’ efforts to establish long- term regulatory strategies in this area that support these goals. We note that the findings from the exception granted to the Da Vinci project are now VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00642 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37177 available.487 We refer readers to the notice that appeared in the Federal Register on April 29, 2025, regarding the availability and locati . 147 / Monday, August 4, 2025 / Rules and Regulations 37177 available.487 We refer readers to the notice that appeared in the Federal Register on April 29, 2025, regarding the availability and location of the HL7 International Da Vinci Project Report (90 FR 17827). The report found that participants were able to successfully use standards-based FHIR APIs to conduct prior authorization transactions, and indicates that scaling adoption of this approach to information sharing is likely to deliver significant benefits to entities currently facing administrative burden associated with prior authorization processes. The findings from this report will continue to inform policy development and future implementation of the policies we are finalizing in this final rule. Comment: Several commenters discussed whether the proposed certification criterion should also address exchange of prior authorization information using the X12 standard. Some commenters recommended that certified health IT should be required to support both an option using X12 as well as an option using FHIR. However, other commenters stated that inclusion of the X12 278 transaction as part of the proposed API would result ld be required to support both an option using X12 as well as an option using FHIR. However, other commenters stated that inclusion of the X12 278 transaction as part of the proposed API would result in needless burden and cost for both providers and health plans, and that exchange partners should leverage the enforcement discretion provided by CMS to avoid mapping the X12 278 transaction as part of the electronic prior authorization API workflow. Response: We did not propose, and are not finalizing, requirements for Health IT Modules certified to the certification criteria at 45 CFR 170.315(g)(31), (32), and (33) to demonstrate conformance or mapping to the X12 278 transaction. We agree with commenters that requiring all such Health IT Modules to include this functionality would increase costs and burden without an associated benefit, as healthcare providers may conduct electronic prior authorization activities without mapping requests to the X12 278 transaction at this time. However, this would not restrict health IT developers, payers, or other intermediaries, from providing for this mapping where such mapping may be necessary to complete electronic prior authorization transacti this would not restrict health IT developers, payers, or other intermediaries, from providing for this mapping where such mapping may be necessary to complete electronic prior authorization transactions with payers via the X12 278 transaction. Comment: Commenters noted that CMS has proposed to adopt the X12 275 standard and Consolidated Clinical Document Architecture (C–CDA) as relevant standards for healthcare attachments. Commenters expressed 487 See https://confluence.hl7.org/spaces/DVP/ pages/113675673/Da+Vinci+HIPAA+Exception. concern that there would be redundancy between this proposal, if finalized, and the proposed use of the Da Vinci FHIR PAS IG proposed for use in the ‘‘prior authorization API—provider’’ criterion. This IG references the Da Vinci Clinical Data Exchange (CDex) IG for attachments, rather than the X12 275 standard and C–CDA proposed by CMS. Commenters believed that these concurrent policies, if finalized, would create confusion for those implementing electronic prior authorization. Response: We recognize that CMS has proposed the use of the C–CDA for attachment information accompanying the X12 275 transaction, including for prior authorization information, prior authorization. Response: We recognize that CMS has proposed the use of the C–CDA for attachment information accompanying the X12 275 transaction, including for prior authorization information, in the Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard proposed rule (87 FR 78438), which appeared in the Federal Register on December 21, 2022. This rule has not been finalized as of the publication of this final rule. We will continue to work with CMS on addressing any potential intersection between the policies in this rulemaking and policies which CMS may finalize in the future around HIPAA administrative simplification standards. (d) Revision and Addition of API Condition and Maintenance of Certification Requirements (i) Background In the HTI–2 Proposed Rule, we made proposals to extend the applicability of the API Conditions of Certification in 45 CFR 170.404(a) and certain API Maintenance of Certification requirements in 45 CFR 170.404(b) to Certified API Developers with Health IT Modules certified to the criteria proposed for tification in 45 CFR 170.404(a) and certain API Maintenance of Certification requirements in 45 CFR 170.404(b) to Certified API Developers with Health IT Modules certified to the criteria proposed for adoption in in 45 CFR 170.315(g)(7) through (10), 45 CFR 170.315(g)(20), 45 CFR 170.315(g)(30)– (36), and 45 CFR 170.315(j). In this final rule, we are only finalizing policies related to one of these proposed criteria, specifically the criterion in 45 CFR 170.315(g)(34). Therefore, in this section, we limit our focus to proposals from the HTI–2 proposed rule relevant to the proposed criterion in 45 CFR 170.315(g)(34). Specifically, we focus on proposals to amend the applicability of the following: the introductory text to 45 CFR 170.404, 45 CFR 170.404(b)(1), 45 CFR 170.404(b)(1)(i), and certain definitions in 45 CFR 170.404(c). In addition to proposals in the HTI– 2 Proposed Rule extending the applicability of 45 CFR 170.404, we also made proposals to update the requirements in 45 CFR 170.404. These proposals were made in tandem with proposals to update other elements of the Certification Program, including proposals to update to the ‘‘standardized API for patient and population ser 70.404. These proposals were made in tandem with proposals to update other elements of the Certification Program, including proposals to update to the ‘‘standardized API for patient and population services’’ criterion in 45 CFR 170.315(g)(10), which we are not finalizing in this final rule. Accordingly, we are not finalizing any of the updates proposed to the requirements in 45 CFR 170.404 in the HTI–2 Proposed Rule, except for changes to the applicability of 45 CFR 170.404 with respect to the specific certification criteria that we are finalizing in this final rule. However, we note that, with respect to proposals in the HTI–2 Proposed Rule to 45 CFR 170.404(a)(2)(i) regarding the technical documentation that a Certified API Developer must make available (89 FR 63592), we are finalizing related requirements within certification criteria being finalized in this rule in 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33). Our proposal in the HTI–2 proposed rule, if finalized, would have included language regarding technical documentation in 45 CFR 170.404(a)(2)(i), which would have been applicable to the proposed ‘‘prior authorization API—provider’’ criterion in 45 CFR 170.315(g)(34), p luded language regarding technical documentation in 45 CFR 170.404(a)(2)(i), which would have been applicable to the proposed ‘‘prior authorization API—provider’’ criterion in 45 CFR 170.315(g)(34), pending the finalization of the proposals to expand the applicability of 45 CFR 170.404 to the criterion in 45 CFR 170.315(g)(34). We believe these technical documentation requirements are important to transparency around the APIs in the criteria we are finalizing in 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33) that are based on the 45 CFR 170.315(g)(34) proposal. Thus, we are finalizing a reference to complete accompanying technical documentation, as proposed in 45 CFR 170.404(a)(2)(i), within the text of the relevant certification criteria in 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33). We direct readers to the finalization of those criteria in this section for more information. (ii) Proposals In the HTI–2 Proposed Rule we proposed to add several proposed certification criteria to the existing list of criteria for which the requirements in 45 CFR 170.404 would apply, unless otherwise specified, which included the criterion in 45 CFR 170.315(g)(34). We stated that if our proposa the existing list of criteria for which the requirements in 45 CFR 170.404 would apply, unless otherwise specified, which included the criterion in 45 CFR 170.315(g)(34). We stated that if our proposals were finalized, this would mean that the API Condition and Maintenance of Certification requirements would apply to developers of Health IT Modules certified to 45 CFR 170.315(g)(34). We stated we believe this approach is VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00643 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37178 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations essential to continue to fulfill the statutory requirements set forth in PHSA section 3001(c)(5)(D)(iv), in particular the statutory requirement that a developer of certified health IT has published application programming interfaces and allows health information from such technology to be accessed, exchanged, and used without special effort. As we described in the ONC Cures Act Final Rule (84 FR 7476 through 7477), we established the API Condition and Maintenance of Certification requirements to, a hanged, and used without special effort. As we described in the ONC Cures Act Final Rule (84 FR 7476 through 7477), we established the API Condition and Maintenance of Certification requirements to, among other outcomes, promote transparency and pro-competitive business practices among Certified API Developers in pursuit of a policy that would result in access, exchange, and use of EHI ‘‘without special effort.’’ We stated we believe that these same requirements should apply to developers of new API- related certification criteria, and that the proposals to reference additional API certification criteria in 45 CFR 170.404 (inclusive of the criterion in 45 CFR 170.315(g)(34)) would continue to adhere to our statutory charge to advance nationwide interoperability. In the HTI–2 Proposed Rule, we proposed that the authenticity verification and registration requirements currently in 45 CFR 170.404(b)(1) should apply to Certified API Developers with a Health IT Module certified to one or more specified certification criteria, including the criterion proposed in 45 CFR 170.315(g)(34). Similarly, we proposed in 45 CFR 170.404(b)(1)(i) that this provision should apply to an expanded set of e specified certification criteria, including the criterion proposed in 45 CFR 170.315(g)(34). Similarly, we proposed in 45 CFR 170.404(b)(1)(i) that this provision should apply to an expanded set of specified certification criteria, which included proposed 45 CFR 170.315(g)(34). Under 45 CFR 170.404(b)(1)(i), a Certified API Developer is permitted to institute a process to verify the authenticity of API Users so long as such process is objective and the same for all API Users and completed within ten business days of receipt of an API User’s request to register their software application for use with the Certified API Developer’s Health IT Module certified to any of a set of specified certification criteria. Finally, we proposed revisions to two key terms in 45 CFR 170.404(c). We proposed to revise certified API technology to mean the capabilities of Health IT Modules that are certified to any of the API-focused certification criteria, including the criterion adopted in 45 CFR 170.315(g)(34). We noted that this revision would support our proposed application of requirements in 45 CFR 170.404 to the proposed APIs in 45 CFR 170.315(g) and the proposed modular API capabilities in 45 (g)(34). We noted that this revision would support our proposed application of requirements in 45 CFR 170.404 to the proposed APIs in 45 CFR 170.315(g) and the proposed modular API capabilities in 45 CFR 170.315(j). We also proposed to revise Certified API Developer to mean a health IT developer that creates ‘‘certified API technology.’’ We stated we believe this simplified definition for Certified API Developer will similarly support this term’s application to the proposed API capabilities in 45 CFR 170.315(g) and proposed modular API capabilities in 45 CFR 170.315(j). The following is a summary of the comments we received and our responses: Comment: Commenters were mixed in their support for our proposals to add the ‘‘prior authorization API—provider’’ criterion in 45 CFR 170.315(g)(34) to the API Conditions and Maintenance of Certification requirements in 45 CFR 170.404. While they supported the transparency requirements, some commenters stated they are duplicative of requirements in the Interoperability and Prior Authorization final rule which include similar transparency requirements. Other commenters noted concerns about applying Fees Conditions to these APIs. They noted that n the Interoperability and Prior Authorization final rule which include similar transparency requirements. Other commenters noted concerns about applying Fees Conditions to these APIs. They noted that the prior authorization APIs are not simple query and retrieve functions. Rather, they are a complex, multi-step, bidirectional conversation between multiple parties. They claimed that prohibiting developers from generating revenue from these complex, orchestration-heavy APIs will significantly impact the willingness of vendors to build and supply these APIs, which will stymie innovation. They recommended that if we finalize the proposals, we should not apply the Fees Conditions to these APIs. Response: We appreciate commenters’ feedback. The regulations we are finalizing reflect a more targeted approach to apply requirements proposed in 45 CFR 170.404 to specific certification criteria in 45 CFR 170.315(g), including the certification criteria at 45 CFR 170.315(g)(31), (g)(32), and (g)(33) we are finalizing in this rule related to electronic prior authorization. For example, we believe that certified health IT developers with Health IT Modules certified to any of the criteria (g)(31) 3) we are finalizing in this rule related to electronic prior authorization. For example, we believe that certified health IT developers with Health IT Modules certified to any of the criteria (g)(31) through (g)(33) ought to abide existing requirements at 45 CFR 170.404(a)(4) for openness and pro- competitive conditions. However, as we discuss further below, we believe that service base URL publication requirements at 45 CFR 170.404(b)(2) should not be applied to the criterion at 45 CFR 170.315(g)(32). We believe this targeted approach will address commenters who saw value in some of the requirements in 45 CFR 170.404, such as the transparency requirements, but were concerned with other requirements. While we understand there are transparency requirements in the recent CMS Interoperability and Prior Authorization rule for specified payers, we do not believe our requirements for certified health IT developers subject to requirements at 45 CFR 170.404 are duplicative. Primarily, we believe there is no duplication because we are not, at this time, finalizing proposed requirements for Health IT Modules intended for use by payers covered by the CMS Interoperability and Prior Authorizat eve there is no duplication because we are not, at this time, finalizing proposed requirements for Health IT Modules intended for use by payers covered by the CMS Interoperability and Prior Authorization rule. The requirements at 45 CFR 170.404(a)(2) for transparency are applicable to Certified API Developers with Health IT Modules certified in 45 CFR 170.315(g)(7) through (10), and, as we are finalizing in this rule, (g)(31), (g)(32), and (g)(33). These criteria are not intended for certification of health IT used by payers subject to the CMS Interoperability and Prior Authorization rule. In regard to concerns with the fees conditions we acknowledge and agree that the electronic prior authorization criteria are not simple query and retrieve functions but rather complex, multi-step, bidirectional conversation between multiple systems. However, we disagree that the fee conditions would prohibit developers from generating revenue to a degree that would deter developers from building and supplying these APIs to customers. We note that several fees are explicitly permitted in 45 CFR 170.404(a)(3)(ii) through (iv) to recover costs associated with deployment, API usage, and value- added supplying these APIs to customers. We note that several fees are explicitly permitted in 45 CFR 170.404(a)(3)(ii) through (iv) to recover costs associated with deployment, API usage, and value- added services. We refer interested parties to the finalized policies related to these permitted fees and the wider set of fees conditions at 45 CFR 170.404(a)(3) in the ONC Cures Act Final Rule (85 FR 25755). Comment: Other commenters supported ASTP/ONC’s extension of new capabilities to the Conditions of Certification and Maintenance of Certification requirements as a means of ensuring Health IT Modules not only implement capabilities, but continue to maintain these capabilities and ensure patients, providers, and payers are able to take advantage of their benefits. Response: We thank commenters for their support. After consideration of the public comment, we are finalizing our proposals, with modification. We are finalizing regulation text at 45 CFR 170.404 to include the phrase ‘‘unless otherwise specified in this section,’’ as proposed. This amendment enables the Certification Program to specify requirements in different subparagraphs VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00 rwise specified in this section,’’ as proposed. This amendment enables the Certification Program to specify requirements in different subparagraphs VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00644 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37179 to pertain to different API-based certification criteria. Given that we are adopting in this final rule API-based certification criteria that require Health IT Module support for server capabilities at 45 CFR 170.315(g)(31) and client capabilities at 45 CFR 170.315(g)(32) and (33), not all requirements in 45 CFR 170.404 are relevant or would be appropriate for both types of capabilities. For example, the requirements at 45 CFR 170.404(b)(2) for publicly publishing FHIR endpoints belonging to a developer of certified health IT’s customers is not relevant for Health IT Modules that support client capabilities, such as certified health IT that is certified to the criterion in 45 CFR 170.315(g)(32). We are finalizing to add references to the certification criteria at 45 CFR that support client capabilities, such as certified health IT that is certified to the criterion in 45 CFR 170.315(g)(32). We are finalizing to add references to the certification criteria at 45 CFR 170.315(g)(31), (g)(32), and (g)(33) to the introductory text at 45 CFR 170.404. Consistent with prior discussion of finalizing multiple criteria to represent the capabilities we proposed in a single criterion in 45 CFR 170.315(g)(34), adding 45 CFR 170.315(g)(31), (g)(32), and (g)(33) to this introductory text would be equivalent to our proposal to include 45 CFR 170.315(g)(34) in the regulation text at 45 CFR 170.404. The addition of these references to the introductory text of 45 CFR 170.404 means that Health IT Modules certified to 45 CFR 170.315(g)(31), (g)(32), and (g)(33) are subject to all requirements listed in 45 CFR 170.404(a)(1) through (4), including fees conditions and openness and pro-competitive conditions, unless otherwise specified. We are finalizing the addition of 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33) at 45 CFR 170.404(b)(1) and 45 CFR 170.404(b)(1)(i). This is similar to what we proposed in the HTI– 2 Proposed Rule because the relevant API Condition and M R 170.315(g)(31) and 45 CFR 170.315(g)(33) at 45 CFR 170.404(b)(1) and 45 CFR 170.404(b)(1)(i). This is similar to what we proposed in the HTI– 2 Proposed Rule because the relevant API Condition and Maintenance of Certification requirements in 45 CFR 170.404 will apply to Health IT Modules certified to the new certification criteria for API technology being finalized in 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33) that reflect capabilities included in the originally proposed ‘‘prior authorization API—provider’’ criterion in 45 CFR 170.315(g)(34). However, we are not finalizing to apply the API Condition and Maintenance of Certification requirements in 45 CFR 170.404(b)(1) to the new certification criterion in 45 CFR 170.315(g)(32) because the authenticity verification and registration for production use requirements under 45 CFR 170.404(b)(1) are not applicable to Health IT Modules certified to 45 CFR 170.315(g)(32). A Health IT Module certified to 45 CFR 170.315(g)(32) supports only client capabilities and is not publishing an API endpoint for applications to register with as part of supporting the ‘‘Full DTR EHR’’ capabilities in at least one of the IGs adopted at 45 CFR 170.2 y client capabilities and is not publishing an API endpoint for applications to register with as part of supporting the ‘‘Full DTR EHR’’ capabilities in at least one of the IGs adopted at 45 CFR 170.215(j)(2). We did not receive any substantive comments regarding our revisions to the definitions for the terms certified API technology and Certified API Developer. However, we are finalizing a revision to the key term as proposed for ‘‘Certified API developer,’’ by removing the duplicative references to criteria in the key term for ‘‘certified API technology.’’ We are also finalizing the key term for ‘‘certified API technology,’’ consistent with what we proposed by including capabilities of Health IT Modules that are certified to certification criteria adopted in 45 CFR 170.315(g)(31), (32), and (33). This will ensure consistent application of these key terms throughout regulation text in 45 CFR 170.404. We are not finalizing any of the other proposals in the HTI–2 proposed rule for changes to the regulatory text at 45 CFR 170.404(a) and 45 CFR 170.404(b) at this time. (e) Revisions to Real World Testing Requirements The Cures Act requires, as Condition and Maintenance of Certificatio es to the regulatory text at 45 CFR 170.404(a) and 45 CFR 170.404(b) at this time. (e) Revisions to Real World Testing Requirements The Cures Act requires, as Condition and Maintenance of Certification requirements under the Certification Program, that health IT developers successfully test the real world use of the technology for interoperability 488 in the type of setting in which such technology would be marketed. As discussed in the ONC Cures Act Final Rule, the objective of real world testing is to verify the extent to which certified health IT deployed in production contexts continues to demonstrate conformance to the full scope of applicable certification criteria and functions with the intended use cases as part of the overall maintenance of a health IT’s certification (85 FR 25766). In the HTI–2 Proposed Rule (89 FR 63594) we discussed that for reasons similar to our proposal to expand requirements in 45 CFR 170.404 to the proposed certification criteria in 45 CFR 170.315(g)(20), (g)(30) through (36), and 170.315(j), we proposed to revise the real world testing requirements in 45 CFR 170.405 by adding these proposed certification criteria in 45 CFR 170.405(a). Given that e 0), (g)(30) through (36), and 170.315(j), we proposed to revise the real world testing requirements in 45 CFR 170.405 by adding these proposed certification criteria in 45 CFR 170.405(a). Given that each of these proposed new certification criteria is 488 Interoperability is defined in statute in section 3000 of the Public Health Service Act (as modified by section 4003 of the Cures Act) and defined in regulation at 45 CFR 170.102. focused on interoperability and data exchange, we stated we believe it is important that developers of certified health IT with Health IT Module(s) certified to these criteria participate in both Condition and Maintenance of Certification requirements. Per requirements in 45 CFR 170.405(b), we also proposed that developers of certified health IT with Health IT Modules certified to any one or more of the certification criteria in 45 CFR 170.315(g)(20), (g)(30) through (36), and 170.315(j) also submit annual real world testing plans as well as annual real world testing results, which applies to any one or more of the criteria referenced in 170.405(a). We noted that by including these criteria in 45 CFR 170.405(a) that health IT developers may voluntarily a d testing results, which applies to any one or more of the criteria referenced in 170.405(a). We noted that by including these criteria in 45 CFR 170.405(a) that health IT developers may voluntarily avail themselves of SVAP flexibility so long as they ensure that their annual real world testing plans and real world testing results submissions address all the versions of all the standards and implementation specifications to which each Health IT Module is certified. Under the narrow scope of this final rule, we are only finalizing policies based on our proposal to reference the criterion at 45 CFR 170.315(g)(34) (which was included in our proposal to reference criteria in (g)(30) through (36) in 45 CFR 170.405(a)), and our proposals to reference criteria in 45 CFR 170.315(j)(20) and 45 CFR 170.315(j)(24) (included in our proposal to reference criteria in 170.315(j) in 45 CFR 170.405(a)), to the real world testing requirements in 45 CFR 170.405. The following is a summary of the comments we received and our responses: Comment: Comments were mixed on the inclusion of certification criteria related to prior authorization as part of real world testing requirements at 45 CFR 170.405. Som we received and our responses: Comment: Comments were mixed on the inclusion of certification criteria related to prior authorization as part of real world testing requirements at 45 CFR 170.405. Some commenters supported our proposal to include prior authorization criteria as part of real world testing because they believed real world testing requirements are critical to ensure products and standards facilitate the intended uses without negative, unintended uses. Other commenters did not believe that real world testing requirements should be applied to electronic prior authorization criteria, noting that payers are already required under the CMS Interoperability and Prior Authorization rule to report annual metrics. Response: We thank commenters for their support and acknowledge those commenters who considered real world testing requirements at 45 CFR 170.405 duplicative of CMS requirements for impacted payers subject to the CMS VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00645 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37180 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules Frm 00645 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37180 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations Interoperability and Prior Authorization rule. Respectfully, we disagree that requirements at 45 CFR 170.405 are duplicative of CMS requirements. Certification criteria established at 45 CFR 170.315(g)(31) through (33) are intended to support providers engaging in prior authorization workflows and real world testing requirements apply to Health IT Modules specified at 45 CFR 170.405(a) and the performance of these Health IT Modules in real-world clinical settings. These requirements do not overlap with the metrics CMS finalized for impacted payers to report on how payers are conducting prior authorization processes (89 FR 8889). After consideration of public comments, we are finalizing updates to 45 CFR 170.405(a) to include the criteria in 45 CFR 170.315(g)(31), (g)(32), and (g)(33). We did not receive any comments regarding the proposed inclusion of criteria in 45 CFR 170.315(j)(20) and 45 CFR 170.315(j)(24) (which we are finalizing in this rule in 45 CFR 170.315(21)) nd (g)(33). We did not receive any comments regarding the proposed inclusion of criteria in 45 CFR 170.315(j)(20) and 45 CFR 170.315(j)(24) (which we are finalizing in this rule in 45 CFR 170.315(21)) as part of real world testing requirements at 45 CFR 170.405, and we are finalizing our proposal to include these criteria. We remind interested parties that inclusion of these criteria at 45 CFR 170.405(a) makes it possible for developers of certified health IT with Health IT Modules certified to these certification criteria to use SVAP to certify their Health IT Modules to newer versions of adopted standards referenced in these criteria. (f) Addition of Criteria to the Base EHR Definition In the HTI–2 Proposed Rule, we noted that the ‘‘prior authorization API— provider’’ certification criteria in 45 CFR 170.315(g)(34) pertains to certified Health IT Modules intended for use by healthcare providers. We stated we believe this certification criterion reflects fundamental capabilities, which would be appropriate for adoption by any healthcare provider using certified health IT. We noted that technology certified to the ‘‘prior authorization API—provider’’ criterion would enable a health h would be appropriate for adoption by any healthcare provider using certified health IT. We noted that technology certified to the ‘‘prior authorization API—provider’’ criterion would enable a healthcare provider to conduct prior authorization requests and related interactions with payers that are widely used today. We proposed to include the certification criterion 45 CFR 170.315(g)(34) to the set of certification criteria adopted by the Secretary that are necessary to meet the Base EHR definition. For the ‘‘prior authorization API—provider’’ certification criterion in 45 CFR 170.315(g)(34), we proposed that this criterion would be necessary to meet the Base EHR definition on and after January 1, 2027. We stated that this date is consistent with the Electronic Prior Authorization measures CMS finalized for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, which program participants must report beginning with the CY 2027 EHR reporting period and CY 2027 performance period/2029 MIPS payment year, respectively (89 FR 8910). The following is a summary of the comments we received and our responses: Comment: A number of commen reporting period and CY 2027 performance period/2029 MIPS payment year, respectively (89 FR 8910). The following is a summary of the comments we received and our responses: Comment: A number of commenters supported our proposal to add the ‘‘prior authorization API—provider’’ to the Base EHR definition in 45 CFR 170.102, stating that developers must provide and support these Health IT Modules in order for clinicians to experience the benefits of electronic prior authorization. Some commenters also supported our proposal to add the ‘‘prior authorization API—provider’’ as of January 1, 2027, stating this would be necessary in order to align with CMS reporting requirements for the Electronic Prior Authorization measures finalized for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. Response: We appreciate commenters’ support. Comment: Other commenters did not agree with our proposal to include the proposed ‘‘prior authorization API— provider’’ criterion in the Base EHR definition. These commenters stated that inclusion in the Base EHR definition would be premature, requiring the functionality as part of certified health IT be PI— provider’’ criterion in the Base EHR definition. These commenters stated that inclusion in the Base EHR definition would be premature, requiring the functionality as part of certified health IT before some providers are ready to use the functionality. Commenters recommended that ASTP/ONC only add the ‘‘prior authorization API—provider’’ criterion to the Base EHR definition once APIs based on the relevant standards have been widely adopted across payers. Response: We appreciate commenters’ concerns with our proposal to add the ‘‘prior authorization API—provider’’ criterion to the Base EHR definition at 45 CFR 170.102. We agree with commenters that healthcare providers’ ability to use the functionality represented by these criteria is contingent upon payers implementing corresponding APIs that can exchange prior authorization information with healthcare providers. In addition, while CMS has finalized requirements for impacted payers to establish Prior Authorization APIs in the Interoperability and Prior Authorization final rule, it is possible that some healthcare providers that purchase a health IT product meeting the Base EHR definition would not submit prior authorization requ perability and Prior Authorization final rule, it is possible that some healthcare providers that purchase a health IT product meeting the Base EHR definition would not submit prior authorization requests to any of the impacted payers under the CMS rule. We further agree that given current usage of these solutions, it may be more appropriate to add this criterion to the Base EHR definition once payer APIs meeting CMS’ requirements have been widely implemented. Finally, we note that electronic prior authorization is not identified as a required capability for a ‘‘qualified EHR’’ under the definition of that term in section 3000 of the PHSA, which serves as the basis for the Base EHR definition as currently established by ASTP/ONC (77 FR 54262). Comment: A number of commenters did not support our proposal to include the ‘‘prior authorization API—provider’’ criterion in the Base EHR definition as of January 1, 2027. Commenters that opposed this proposal noted that implementation of the capabilities reflected in the criterion will require a significant amount of development work for health IT developers, as well as substantial time to roll out new functionality to customers. Another co pabilities reflected in the criterion will require a significant amount of development work for health IT developers, as well as substantial time to roll out new functionality to customers. Another commenter noted that the IGs we proposed to reference in the criterion contain ambiguous requirements, and that resolving this ambiguity will require additional development time, recommending that ASTP/ONC delay the deadline for inclusion in the Base EHR definition to January 1, 2028. Commenters acknowledged that the January 1, 2027, deadline was chosen in order to align with the January 1, 2027, deadline that CMS has finalized for impacted payers to establish the API requirements finalized in the Interoperability and Prior Authorization final rule. However, they contended that due to the challenges described in meeting this deadline, ASTP/ONC should work with CMS to delay these deadlines to January 1, 2028. Response: We appreciate commenters’ concerns regarding the proposed deadline of January 1, 2027, for inclusion of the ‘‘prior authorization API—provider’’ criterion in the Base EHR definition. We acknowledge that the proposed date of January 1, 2027 was intended to align with both CM ary 1, 2027, for inclusion of the ‘‘prior authorization API—provider’’ criterion in the Base EHR definition. We acknowledge that the proposed date of January 1, 2027 was intended to align with both CMS requirements for the implementation of Prior Authorization APIs by impacted payers, and that implementation of these electronic prior authorization capabilities may require novel development work for health IT developers. As discussed previously, CMS has finalized that participants in the Medicare Promoting Interoperability VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00646 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37181 Program and the MIPS Promoting Interoperability performance category must report on the respective Electronic Prior Authorization measure included in these programs in an EHR reporting period in CY 2027 or the CY 2027 performance period/2029 MIPS payment year, respectively. The criteria we are finalizing in this rule in 45 CFR 170.315(g)(31), (32), and (33) specify requirements for certified Health 7 or the CY 2027 performance period/2029 MIPS payment year, respectively. The criteria we are finalizing in this rule in 45 CFR 170.315(g)(31), (32), and (33) specify requirements for certified Health IT Modules to enable eligible hospitals, CAHs, and eligible clinicians to interact with the payer Prior Authorization APIs from which these providers and clinicians must request prior authorization in order to complete the action specified in the measures. We will work with CMS to continue to monitor timelines related to the use of certified health IT in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. After consideration of the public comment, we are not finalizing the proposed inclusion in the Base EHR definition of the ‘‘prior authorization API—provider’’ criterion. We further clarify that we are also not finalizing to add to the Base EHR definition the three electronic prior authorization criteria in 45 CFR 170.315(g)(31), (32), and (33) that we are finalizing in this rule based on the proposed ‘‘prior authorization API—provider’’ criterion. As a result of not finalizing any updates to the Base EHR definition, we are als 32), and (33) that we are finalizing in this rule based on the proposed ‘‘prior authorization API—provider’’ criterion. As a result of not finalizing any updates to the Base EHR definition, we are also not finalizing a date of January 1, 2027, for inclusion in the Base EHR definition. (g) Additional Implementation Specifications for Provider, Patient, and Payer APIs In the HTI–2 Proposed Rule, we proposed to adopt API implementation specifications, on behalf of the Secretary, in 45 CFR 170.215(k), (m), and (n), and make these specifications available for HHS use. At the same time, we proposed health IT certification criteria in 45 CFR 170.315(g)(30) through (36) which incorporated these implementation specifications into certification requirements under the Certification Program. In this final rule we are only finalizing criteria (at 45 CFR 170.315(31), (32), and (33)) based on the proposed ‘‘prior authorization API— provider’’ criterion in 45 CFR 170.315(34). However, as discussed in the proposed rule, these implementation specifications address certain use cases for exchange of health information independent of inclusion in a certified Health IT Module, and we therefore proposed the proposed rule, these implementation specifications address certain use cases for exchange of health information independent of inclusion in a certified Health IT Module, and we therefore proposed to adopt these implementation specifications under PHSA section 3004 to make them available for HHS use.489 In the HTI–2 Proposed Rule (89 FR 63582), we proposed to adopt the HL7 FHIR® Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1— STU 2 (PDex US Drug Formulary IG) 490 in 45 CFR 170.215(m)(1) and incorporate it by reference in 45 CFR 170.299(g). We proposed to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. We stated that this implementation specification can enable consumers, members, and patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans. We proposed to adopt the HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.0.0— STU2 491 in 45 CFR 170.215(k)(2)(i) and incorporate it by reference in 45 CFR 170.299(g) (89 FR 63582 and 63583). We proposed to adopt this implementa hange (PDex) Implementation Guide, Version 2.0.0— STU2 491 in 45 CFR 170.215(k)(2)(i) and incorporate it by reference in 45 CFR 170.299(g) (89 FR 63582 and 63583). We proposed to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. This implementation specification enables a payer to create a member’s health history using clinical resources based on US Core profiles. We noted that a version 2.1.0 of the PDex IG was under development and available for interested parties to review at the time of the proposed rule.492 We proposed as an alternative to adopt PDex IG version 2.1.0 if the standard is balloted and published before the issuance of this final rule. We noted several important enhancements in the PDex IG version 2.1.0 to align with the Interoperability and Patient Access Final Rule (85 FR 25522 through 25569) and the Interoperability and Prior Authorization Final Rule (89 FR 8768 through 8946). For example, we noted that version 2.1.0 supports US Core 6.1.0, which supports USCDI v3, as well as drops required support for aspects of prior authorization that are viewed as unnecessary or complicating to successful execution of the tran supports US Core 6.1.0, which supports USCDI v3, as well as drops required support for aspects of prior authorization that are viewed as unnecessary or complicating to successful execution of the transaction in version 2.0.0 of the PDex IG. We also stated that version 2.1.0 includes an important use case for bulk data access based on the finalization of the Bulk 489 See, for example, 89 FR 63582 for discussion of the proposed criterion at 45 CFR 170.315(g)(30) and the benefits of the IG proposed for adoption in 45 CFR 170.215(m). 490 See https://hl7.org/fhir/us/davinci-drug- formulary/STU2.0.1/. 491 See https://hl7.org/fhir/us/davinci-pdex/ STU2/. 492 See https://build.fhir.org/ig/HL7/davinci- epdx/. Data Access IG as a required standard under the Payer API requirements finalized in CMS’ rules. We stated that continued alignment among industry, government, and standards development organizations involved with the payer data exchange use cases is necessary and we stated that if PDex IG version 2.1.0 was balloted and published before issuance of this final rule, adoption of version 2.1.0 would support such alignment. We further proposed to adopt the HL7 FHIR® CARIN Consumer Directed version 2.1.0 was balloted and published before issuance of this final rule, adoption of version 2.1.0 would support such alignment. We further proposed to adopt the HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button® ) Implementation Guide version 2.0.0—STU 2 493 in 45 CFR 170.215(k)(1)(i) and incorporate it by reference in 45 CFR 170.299(g) (89 FR 63583–63584). We proposed to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. We stated that this implementation specification supports providing a set of resources that payers can display to consumers, primarily financial (claims and encounter) data, with some limited associated clinical data. We proposed to adopt the HL7 FHIR Da Vinci Payer Data Exchange Plan Net implementation specification in 45 CFR 170.215(n)(1) and incorporate it by reference in 45 CFR 170.299(g) (89 FR 63592). We proposed to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. Use of this implementation specification can enable third parties to develop applications through which consumers and providers can query the participants in a payer’ nd make it available for HHS use. Use of this implementation specification can enable third parties to develop applications through which consumers and providers can query the participants in a payer’s network that may provide services that address their healthcare needs. The following is a summary of the comments we received and our responses. Comment: A commenter expressed support for our proposal to adopt the CARIN IG for Blue Button, stating that the IG brings value to consumers seeking to access their health information and to payers working to provide such access, and noting that the CARIN IG for Blue Button has already been identified as part of meeting federal requirements. Another commenter supported the use of the CARIN IG for Blue Button as well as the proposed Da Vinci PDex IG to support standardization and effective data exchange across payers, providers, and patients, noting that these implementation guides could enable better data access that will be beneficial for children and families with complex care and coverage circumstances. A 493 See https://hl7.org/fhir/us/carin-bb/. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00647 Fmt 4701 Sfmt 4700 E:\FR\F ren and families with complex care and coverage circumstances. A 493 See https://hl7.org/fhir/us/carin-bb/. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00647 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37182 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations commenter supported the adoption of the PDex US Drug Formulary IG. Several commenters expressed support for ASTP/ONC’s proposal to adopt the PDex Plan Net IG, stating that this IG would help to improve the interoperability of provider directory information. Response: We appreciate the support from commenters for these proposals. Comment: Several commenters recommended adopting new versions of the IGs proposed in the HTI–2 Proposed Rule. Specifically, commenters recommended adopting the PDex IG version 2.1.0 and version 2.1.0 of the CARIN IG for Blue Button. A commenter recommended that ASTP/ONC work with CMS and standards development bodies to ensure that the most updated versions of the standards are adopted and to develop an ongoing versioning strategy. Response: We appreciate commenters’ recommendations reg tandards development bodies to ensure that the most updated versions of the standards are adopted and to develop an ongoing versioning strategy. Response: We appreciate commenters’ recommendations regarding the adoption of newer versions of certain proposed specifications that have been released subsequent to the HTI–2 proposed rule. We have been anticipating publication of version 2.1.0 of the PDex IG and described its many important benefits in the HTI–2 Proposed Rule.494 Given the number of substantial and important updates included in the version 2.1.0 of the PDex IG, and the several commenters supportive of our alternative proposal to adopt 2.1.0, we believe there are strong reasons to finalize adoption of version 2.1.0. In addition to the benefits afforded by the newer version, finalization of the 2.1.0 version of the PDex IG will help avoid industry burden and sunk costs in comparison to our proposed adoption of version 2.0.0 of the IG, which was the version of the IG available at the time of the publication of the proposed rule. Finally, the 2.1.0 version of the PDex IG includes important updates to better implement requirements finalized by CMS in the Interoperability and at the time of the publication of the proposed rule. Finally, the 2.1.0 version of the PDex IG includes important updates to better implement requirements finalized by CMS in the Interoperability and Prior Authorization final rule. While CMS currently recommends use of the PDex IG in the final rule, CMS has stated that they may consider requiring this and other recommended standards in the future, similar to current requirements to use standards adopted in 45 CFR 170.215 and 45 CFR 170.213 (89 FR 8939 through 8941). We believe that adopting the 2.1.0 version of the IG at this time could support future CMS requirements. Regarding updates to the other proposed standards, we note that an updated 2.1.0 version of the CARIN IG for Blue Button, which was also identified by commenters, was published on February 18, 2025. We agree with commenters that updated versions of these specifications may include important updates to align with newer versions of supporting standards, and ongoing changes that reflect the standards development community’s efforts to incrementally improve these specifications. Unlike the PDex IG proposal, we did not propose an alternate proposal to adopt the CARIN IG f that reflect the standards development community’s efforts to incrementally improve these specifications. Unlike the PDex IG proposal, we did not propose an alternate proposal to adopt the CARIN IG for Blue Button version 2.1.0. We only proposed version 2.0.0. Accordingly, we believe it is most appropriate to adopt the versions of the CARIN IG and the other specifications that we proposed in the HTI–2 Proposed Rule. We note that ASTP/ONC will monitor future versions of these specifications. After consideration of the public comment, we are adopting the following implementation specifications in 45 CFR 170.215 and incorporating them by reference in 45 CFR 170.299(g): • HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button® ) Implementation Guide, Version 2.0.0—STU 2 US (45 CFR 170.215(k)(1)(i). • HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.1.0—STU 2.1 (45 CFR 170.215(k)(2)(i)). • HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1— STU2 (45 CFR 170.215(m)(1)). • HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0— STU1.1 US (45 CFR 170.2 S Drug Formulary Implementation Guide, Version 2.0.1— STU2 (45 CFR 170.215(m)(1)). • HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0— STU1.1 US (45 CFR 170.215(n)(1)). We reiterate that at this time we are not finalizing the health IT certification criteria we proposed in the HTI–2 Proposed Rule that referenced these implementation specifications. Rather, as proposed, we are finalizing adoption of these implementation specifications under PHSA section 3004 for HHS use. (7) Corrections for HTI–2 Final Rule In Federal Register document 2024– 29163 (89 FR 101772) final rule titled ‘‘Health Data, Technology, and Interoperability: Trusted Exchange Framework and Common Agreement’’ (HTI–2) (hereinafter referred to as the HTI–2 Final Rule), we identified certain technical and typographical errors following publication in the Federal Register on December 16, 2024. a. Summary of Errors In the ONC Cures Act Final Rule, we finalized 45 CFR 170.550(m) ‘‘time- limited certification and certification status for certain 2015 Edition certification criteria,’’ which provided that for five specific certification criteria, an ONC–ACB may only issue a certific me- limited certification and certification status for certain 2015 Edition certification criteria,’’ which provided that for five specific certification criteria, an ONC–ACB may only issue a certification to a Health IT Module and permit continued certified status for a specified time period (85 FR 25952). The five criteria with time-limited certification and certification status were ‘‘drug-formulary and preferred drug list checks’’ certification criterion (45 CFR 170.315(a)(10)), ‘‘patient- specific education resources’’ (45 CFR 170.315(a)(13)), ‘‘data export’’ certification criterion (45 CFR 170.315 (b)(6)), ‘‘secure messaging’’ certification criterion (45 CFR 170.315(e)(2)), and ‘‘application access—data category request’’ (45 CFR 170.315(g)(8)). Because the specified time periods for certification to these criteria have elapsed, we noted in the preamble of the HTI–2 Proposed Rule that we proposed to remove all of the certification criteria referenced in 45 CFR 170.550(m) in one action by removing 45 CFR 170.550(m) in its entirety (89 FR 63615 through 63616). In the HTI–2 Final Rule, we also removed and reserved these aforementioned certification criteria from the specific CFR ction by removing 45 CFR 170.550(m) in its entirety (89 FR 63615 through 63616). In the HTI–2 Final Rule, we also removed and reserved these aforementioned certification criteria from the specific CFR locations in which they were adopted (89 FR 101776 through 101777). However, we inadvertently included a reference to 45 CFR 170.315(g)(2) to remove and reserve in the amendatory instructions for 45 CFR 170.315 (89 FR 101809) when it should read 45 CFR 170.315(g)(8). We also inadvertently omitted from amendatory instruction for 45 CFR 170.550(m) (89 FR 101810), an instruction to remove 45 CFR 170.550(m). In the HTI–2 Final Rule (89 FR 101776) preamble, we intended to finalize as proposed removal and reservation of 45 CFR 170.315(g)(8). However, we erroneously included a reference to 45 CFR 170.315(g)(2) instead of 45 CFR 170.315(g)(8) in the amendatory instructions, which resulted in the removal of 45 CFR 170.315(g)(2) and retention of 45 CFR 170.315(g)(8) (89 FR 101809). We therefore add 45 CFR 170.315(g)(2) back into the CFR and remove 45 CFR 170.315(g)(8) to address this error. Section 170.315(g)(2) refers to automated measure calculation. The language to be inserted into the CFR i 45 CFR 170.315(g)(2) back into the CFR and remove 45 CFR 170.315(g)(8) to address this error. Section 170.315(g)(2) refers to automated measure calculation. The language to be inserted into the CFR is ‘‘Automated measure calculation. For each Promoting Interoperability Programs percentage-based measure that is supported by a capability included in a technology, record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable measure.’’ In the HTI–2 Final Rule (89 FR 101776) preamble, we also intended to finalize as proposed the removal of 45 VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00648 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37183 CFR 170.550(m). However, we omitted the amendatory language instructing the Office of the Federal Register to remove 45 CFR 170.550(m) in the regulatory text. the policies finalized in the HTI–2 Final Rule. Therefore, we believe we have good cause to waive the notice and comment and effective eral Register to remove 45 CFR 170.550(m) in the regulatory text. the policies finalized in the HTI–2 Final Rule. Therefore, we believe we have good cause to waive the notice and comment and effective date requirements. b. Waiver of Proposed Rulemaking, Comment Period, and Delay in Effective Date Under 5 U.S.C. 553(b) of the Administrative Procedure Act (APA), the agency is required to publish a notice of the proposed rulemaking in the Federal Register before the provisions of a rule take effect. In addition, section 553(d) of the APA mandates a 30-day delay in effective date after issuance or publication of a rule. Sections 553(b)(B) and 553(d)(3) of the APA provide for exceptions from the notice and comment and delay in effective date requirements. Section 553(b)(B) of the APA provides an exception to the requirement that an agency publish a notice of proposed rulemaking in the Federal Register for good cause if the agency makes and incorporates a finding, to include a brief statement of reasons, that the notice and comment process are impracticable, unnecessary, or contrary to the public interest. In addition, section 553(d)(3) of the APA allows the agency to avoid the 30-day de t of reasons, that the notice and comment process are impracticable, unnecessary, or contrary to the public interest. In addition, section 553(d)(3) of the APA allows the agency to avoid the 30-day delay in effective date for good cause and where the agency includes a statement of support. We believe this correction does not constitute a rule that would be subject to the APA notice and comment or delayed effective date requirements. This document corrects technical and typographical errors in the preamble and regulation text of the HTI–2 Final Rule, but it does not make substantive changes to the policies that were adopted in the HTI–2 Final Rule. As a result, this correction is intended to ensure that the information in the HTI– 2 Final Rule accurately reflects the policies adopted in that document. In addition, even if this were a rule to which the notice and comment procedures and delayed effective date requirements applied, we find that there is good cause to waive such procedures and requirements. Undertaking further notice and comment procedures to incorporate the corrections in this document into the HTI–2 Final Rule would be contrary to the public interest because it is in and requirements. Undertaking further notice and comment procedures to incorporate the corrections in this document into the HTI–2 Final Rule would be contrary to the public interest because it is in the public’s interest for entities to receive accurate information regarding the relevant policies, and these corrections ensure the HTI–2 Final Rule reflects the policies laid out in the ONC Cures Act and HTI–2 Final Rules. This correction is intended solely to ensure that the HTI–2 Final Rule accurately reflects applicable law, and (8) Incorporation by Reference The Office of the Federal Register has established requirements for materials (for example, standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). Specifically, § 51.5(b)(2) requires agencies to discuss, in the preamble of a final rule, the ways that the materials they incorporate by reference are reasonably available to interested parties and how interested parties can obtain the materials; and summarize, in the preamble of the final rule, the material they incorporate by reference. To make the materials we intend to inco ested parties and how interested parties can obtain the materials; and summarize, in the preamble of the final rule, the material they incorporate by reference. To make the materials we intend to incorporate by reference reasonably available, we provide a uniform resource locator (URL) for the standards and implementation specifications. In many cases, these standards and implementation specifications are directly accessible through the URLs provided. In most of these instances, access to the standard or implementation specification can be gained through no-cost (monetary) participation, subscription, or membership with the applicable standards developing organization (SDO) or custodial organization. Alternatively, a copy of the standards may be viewed for free at the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201. Please call (202) 690–7171 in advance to arrange inspection. The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A–119 require the use of, wherever practical, technical ational Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A–119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A–119 provide exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. As discussed in section III.A.1 of the HTI–2 Proposed Rule, we have followed the NTTAA and OMB Circular A–119 in proposing standards and implementation specifications for adoption, including describing any exceptions in the proposed adoption of standards and implementation specifications (89 FR 63514). Over the years of adopting standards and implementation specifications for certification, we have worked with SDOs, such as HL7, to make the standards we propose to adopt, and subsequently adopt and incorporate by reference in the Federal Register, available to interested parties. As described previously, this in , such as HL7, to make the standards we propose to adopt, and subsequently adopt and incorporate by reference in the Federal Register, available to interested parties. As described previously, this includes making the standards and implementation specifications available through no-cost memberships and no- cost subscriptions. As required by § 51.5(b), we provide summaries of the standards we are adopting and incorporating by reference in the Code of Federal Regulations. We also provide relevant information about these standards and implementation specifications throughout the preamble. We have organized the following standards and implementation specifications that we are adopting through this rulemaking according to the sections of the Code of Federal Regulations (CFR) in which they would be codified and cross-referenced for associated certification criteria and requirements that we are adopting. (a) Vocabulary Standards for Representing Electronic Health Information—45 CFR 170.207 • RxNorm, December 4, 2023, Full Update Release. URL: https://www.nlm.nih.gov/ research/umls/rxnorm/docs/ rxnormarchive.html Access requires a user account and license agreement. There is no monetary co RxNorm, December 4, 2023, Full Update Release. URL: https://www.nlm.nih.gov/ research/umls/rxnorm/docs/ rxnormarchive.html Access requires a user account and license agreement. There is no monetary cost for a user account and license agreement. Summary: RxNorm, a standardized nomenclature for clinical drugs, is produced by the National Library of Medicine. RxNorm’s standard identifiers and names for clinical drugs are connected to the varying names of drugs present in many different controlled vocabularies within the Unified Medical Language System (UMLS) Metathesaurus, including those in commercially available drug information sources. These connections are intended to facilitate interoperability among the computerized systems that record or process data dealing with clinical drugs. (b) Application Programming Interface Standards—45 CFR 170.215 • HL7 FHIR® CDS Hooks Implementation Guide, Version 2.0.1— STU 2 Release 2, March 12, 2025. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00649 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37184 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / R 00000 Frm 00649 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37184 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations URL: https://cds-hooks.hl7.org/STU2/ This is a direct access link. Summary: This HL7 FHIR® CDS Hooks Implementation Guide describes a ‘‘hook’’ based pattern for invoking clinical decision support (CDS) from within a clinician’s workflow. The APIs described in the specification support synchronous, workflow-triggered CDS calls returning information and suggestions, and launching a user-facing SMART app when CDS requires additional interaction. • HL7 FHIR® Subscriptions R5 Backport Implementation Guide, Version 1.1.0—Standard for Trial Use, draft as of January 11, 2023. URL: https://hl7.org/fhir/uv/ subscriptions-backport/STU1.1/ This is a direct access link. Summary: The Subscription R5 Backport Implementation Guide enables servers running versions of FHIR earlier than R5 to implement a subset of R5 Subscriptions in a standardized way. During the development of FHIR R5, the Subscriptions Framework has gone through a significant redesign. Many implementers have expre R5 to implement a subset of R5 Subscriptions in a standardized way. During the development of FHIR R5, the Subscriptions Framework has gone through a significant redesign. Many implementers have expressed a need for functionality from the FHIR R5 version of Subscriptions to be made available in FHIR R4. The goal of publishing the Subscription R5 Backport Implementation Guide is to define a standard method of back-porting the R5 Subscriptions Framework for greater compatibility and adoption by systems leveraging an early version of FHIR (that is, FHIR R4). • HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.1.0—STU 2.1, June 18, 2025. URL:https://hl7.org/fhir/us/davinci- pdex/STU2.1/ This is a direct access link. Summary: The Payer Data Exchange (PDex) Implementation Guide is provided for payers/health plans to enable them to create a Member’s Health History using clinical resources (based on US Core Profiles established from FHIR R4) which can be understood by providers and, if they choose to, committed to their Electronic Medical Records (EMR) System. • HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1— STU 2, by providers and, if they choose to, committed to their Electronic Medical Records (EMR) System. • HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1— STU 2, January 8, 2024. URL:https://hl7.org/fhir/us/davinci-crd/ STU2/ This is a direct access link. Summary: The Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide defines a workflow to allow payers to provide information about coverage requirements to healthcare providers through their provider systems at the time treatment decisions are being made. This will ensure that clinicians and administrative staff have the capability to make informed decisions and meet the requirements of the patient’s insurance coverage. • HL7 FHIR® Da Vinci— Documentation Templates and Rules (DTR) Implementation Guide, Version 2.0.1—STU 2, January 11, 2024. URL:https://hl7.org/fhir/us/davinci-dtr/ STU2/ This is a direct access link. Summary: The Da Vinci Documentation Templates and Rules (DTR) Implementation Guide provides a mechanism for payers to express their documentation requirements computably in a way that allows clinicians and other EHR users to navigate and quickly specify the needed inf entation Guide provides a mechanism for payers to express their documentation requirements computably in a way that allows clinicians and other EHR users to navigate and quickly specify the needed information in a context-specific way. The guide allows rules to be written in a way that supports automatically extracting existing EHR information for review/confirmation and adjusting the information prompted for based on what data is already known or entered, minimizing impact on provider time, while expediting subsequent payer interactions. • HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.0.1— STU 2, December 1, 2023. URL: https://hl7.org/fhir/us/davinci- pas/STU2/ This is a direct access link. Summary: The Da Vinci Prior Authorization Support (PAS) Implementation Guide enables direct submission of prior authorization requests from EHR systems using FHIR. The implementation guide also defines capabilities around the management of prior authorization requests, including checking the status of a previously submitted request, updating a previously submitted request, and canceling a request. Direct submission of prior authorization requests from tion requests, including checking the status of a previously submitted request, updating a previously submitted request, and canceling a request. Direct submission of prior authorization requests from the EHR can result in faster prior authorization decisions, reducing costs for both providers and payers and improving patient experience. • HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button® ) Implementation Guide, Version 2.0.0—STU 2 US, November 28, 2022. URL: https://hl7.org/fhir/us/carin-bb/ STU2/ This is a direct access link. Summary: This implementation guide describes the CARIN for Blue Button® Framework and Common Payer Consumer Data Set (CPCDS), providing a set of resources that payers can display to consumers via a FHIR API. The CARIN for Blue Button IG was defined by the CARIN Alliance to meet the requirements in the CMS Interoperability and Patient Access final rule for impacted payers to make available claims and encounter data via a Patient Access API. This IG is primarily used to exchange financial (claims and encounter) data, with some limited associated clinical data. • HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Impl ess API. This IG is primarily used to exchange financial (claims and encounter) data, with some limited associated clinical data. • HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1— STU 2, December 1, 2023. URL: https://hl7.org/fhir/us/davinci- drug-formulary/STU2.0.1/ This is a direct access link. Summary: This implementation guide defines a FHIR interface to a health insurer’s drug formulary information for patients/consumers. The primary use cases for this FHIR interface enable consumers/members/patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans. • HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0— STU1.1 US, April 4, 2022. URL: https://hl7.org/fhir/us/davinci- pdex-plan-net/STU1.1/ This is a direct access link. Summary: This implementation guide defines a FHIR interface to access information about a health insurer’s insurance plans, their associated networks, and the organizations and providers that participate in these networks. Publication of this data through a standard FHIR-based API about a health insurer’s insurance plans, their associated networks, and the organizations and providers that participate in these networks. Publication of this data through a standard FHIR-based API will enable third parties to develop applications through which consumers and providers can query the participants in a payer’s network that may provide services that address their healthcare needs. C. Finalization of Interim Final Action With Comment Period on the Changes to the Fiscal Year 2025 Hospital IPPS Rates Due to Court Decision (CMS– 1808–IFC) In the interim final action with comment period (IFC) (CMS–1808–IFC), that appeared in the October 3, 2024 Federal Register (89 FR 80405) (hereinafter referred to as the FY 2025 IFC), CMS implemented revised Medicare wage index values for FY 2025, established a transitional payment exception for low wage hospitals significantly impacted by those VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00650 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37185 revisions, and made confo AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37185 revisions, and made conforming changes to the hospital IPPS payment rates for FY 2025. These changes reflect the removal of the low wage index hospital policy following the appellate court decision in Bridgeport Hosp. v. Becerra. That IFC also made conforming changes to IPPS rates and factors used to determine certain payments under the LTCH PPS for FY 2025. In this section of this final rule, we are responding to the public comments that we received on the FY 2025 IFC and finalizing the interim final policies established therein. 1. Provisions of the Interim Final Action With Comment Period a. Background In the FY 2020 IPPS/LTCH PPS final rule (84 FR 42325 through 42339), we finalized a policy to address wage index disparities, based in part on comments we received in response to our request for information included in our FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20372 through 20377). In the FY 2020 IPPS/LTCH PPS final rule, based on those public comments and the growing disparities between wage index value ded in our FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20372 through 20377). In the FY 2020 IPPS/LTCH PPS final rule, based on those public comments and the growing disparities between wage index values for high- and low-wage-index hospitals, we explained that those growing disparities are likely caused, at least in part, by the use of historical wage data to prospectively set hospitals’ wage indexes. That lag between when hospitals increase wages and when those wage increases are reflected in the historical data creates barriers to hospitals with low wage index values being able to increase employee compensation, because those hospitals will not receive corresponding increases in their Medicare payment for several years (84 FR 42327). Accordingly, we finalized a policy that provided certain low wage index hospitals with an opportunity to increase employee compensation without the usual lag in those increases being reflected in the calculation of the wage index (as they would expect to do if not for the lag).495 We accomplished this by temporarily increasing the wage index values for 495 In the FY 2020 IPPS/LTCH PPS proposed rule, we agreed with respondents to a previous request for do if not for the lag).495 We accomplished this by temporarily increasing the wage index values for 495 In the FY 2020 IPPS/LTCH PPS proposed rule, we agreed with respondents to a previous request for information who indicated that some current wage index policies create barriers to hospitals with low wage index values from being able to increase employee compensation due to the lag between when hospitals increase the compensation and when those increases are reflected in the calculation of the wage index. We noted that this lag results from the fact that the wage index calculations rely on historical data. We also agreed that addressing this systemic issue did not need to wait for comprehensive wage index reform given the growing disparities between low and high wage index hospitals, including rural hospitals that may be in financial distress and facing potential closure (84 FR 19394 and 19395). certain hospitals with low wage index values and doing so in a budget neutral manner through an adjustment applied to the standardized amounts for all hospitals. We increased the wage index for hospitals with a wage index value below the 25th percentile wage index value for a fiscal year b gh an adjustment applied to the standardized amounts for all hospitals. We increased the wage index for hospitals with a wage index value below the 25th percentile wage index value for a fiscal year by half the difference between the otherwise applicable final wage index value for a year for that hospital and the 25th percentile wage index value for that year across all hospitals (the low wage index hospital policy). As explained in the FY 2020 IPPS/LTCH PPS proposed rule (84 FR 19396) and final rule (84 FR 42329), we indicated that the Secretary has authority to implement the low wage index hospital policy proposal under both section 1886(d)(3)(E) of the Act and section 1886(d)(5)(I) of the Act. When we adopted the low wage index hospital policy in the FY 2020 IPPS/ LTCH PPS final rule (84 FR 42326 through 42328), we stated our intention that this policy would be effective for at least 4 years, beginning in FY 2020, to allow employee compensation increases implemented by these hospitals sufficient time to be reflected in the wage index calculation. We also stated we intended to revisit the issue of the duration of this policy in future rulemaking as we gained experience under the ls sufficient time to be reflected in the wage index calculation. We also stated we intended to revisit the issue of the duration of this policy in future rulemaking as we gained experience under the policy. For FY 2024, we continued to apply the low wage index hospital policy and the related budget neutrality adjustment (88 FR 58977 through 58980). In the FY 2025 IPPS/ LTCH PPS final rule (89 FR 69301 through 69308), we adopted an extension of the low wage index hospital policy and the related budget neutrality adjustment effective for at least three more years, beginning in FY 2025, in order for sufficient wage data from after the end of the COVID–19 Public Health Emergency to become available. In that same FY 2025 IPPS/LTCH PPS final rule (89 FR 69302), we also noted that the FY 2020 low wage index hospital policy and the related budget neutrality adjustment are the subject of pending litigation in multiple courts, and that on July 23, 2024, the Court of Appeals for the D.C. Circuit held that the Secretary lacked authority under section 1886(d)(3)(E) of the Act or under the ‘‘adjustments’’ language of section 1886(d)(5)(I)(i) of the Act to adopt the low wage index hospital polic held that the Secretary lacked authority under section 1886(d)(3)(E) of the Act or under the ‘‘adjustments’’ language of section 1886(d)(5)(I)(i) of the Act to adopt the low wage index hospital policy for FY 2020, and that the policy and related budget neutrality adjustment must be vacated. Bridgeport Hosp. v. Becerra, 108 F.4th 882, 887–91 & n.6 (D.C. Cir. 2024). We also stated that as of the date of that final rule’s publication, the time to seek further review of the D.C. Circuit’s decision in Bridgeport Hospital had not expired (see Fed. R. App. P. 40(a)(1)) and the government was evaluating the decision and considering options for next steps. b. Revised IPPS Wage Index Values for FY 2025 and Transitional Payment Exception for Low Wage Hospitals Significantly Impacted by Those Revisions After considering the D.C. Circuit’s decision in Bridgeport Hosp. v. Becerra, in the FY 2025 IFC we recalculated the IPPS hospital wage index to remove the low wage index hospital policy for FY 2025. Because we were now no longer applying the low wage index hospital policy in FY 2025, we also removed the low wage index budget neutrality factor from the FY 2025 standardized amounts. (89 FR 80407 5. Because we were now no longer applying the low wage index hospital policy in FY 2025, we also removed the low wage index budget neutrality factor from the FY 2025 standardized amounts. (89 FR 80407 through 80408).In the past, we have established temporary transition policies when there have been significant changes to payment policies, and we have limited the duration of each transition in order to phase in the effects of those payment policy changes. In taking this temporary approach in the past, we have sought to mitigate short-term instability and payment fluctuations that can negatively impact hospitals. For example, CMS has recognized that hospitals in certain areas may experience a negative impact on their IPPS payment due to the adoption of revised OMB delineations for wage index purposes and has finalized transition policies to mitigate negative financial impacts and provide stability to year-to-year wage index variations. We refer readers to the FY 2015 IPPS/ LTCH PPS final rule (79 FR 49956 through 49962) for a discussion of the transition period finalized when CMS adopted revised OMB delineations after the 2010 decennial census. We stated in the FY 2025 IFC that for F rule (79 FR 49956 through 49962) for a discussion of the transition period finalized when CMS adopted revised OMB delineations after the 2010 decennial census. We stated in the FY 2025 IFC that for FY 2025, consistent with our past practice, we believe it is appropriate to establish a transition policy for hospitals significantly impacted by the removal of the FY 2025 low wage index hospital policy using our authority under section 1886(d)(5)(I) of the Act. Further, we discussed our current wage index cap policy at 42 CFR 412.64(h)(7), under which we apply a 5-percent cap on any decrease to a hospital’s wage index from its wage index in the prior FY in a budget neutral manner, regardless of the circumstances causing the decline, so that a hospital’s final wage index for the upcoming fiscal year will not be less than 95 percent of its final wage index from the prior fiscal year. In accordance with 42 CFR 412.64(e)(1)(ii), CMS applies a budget neutrality adjustment VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00651 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37186 Federal Register / Vol. 90, No. 147 6 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00651 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37186 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations to offset the increase in total payments resulting from the application of that cap (89 FR 80407). As discussed in the FY 2025 IFC (89 FR 80407 through 80408), some hospitals that benefitted from the low wage index hospital policy previously will experience decreases of 5 percent or more from their FY 2024 wage index to the FY 2025 wage index established in that IFC. Similar to how 42 CFR 412.64(h)(7) operates, in that IFC we applied a one-time, transitional adjustment to create a narrow transitional exception to the calculation of FY 2025 payments. The wage index cap policy at 42 CFR 412.64(h)(7) would have mitigated these FY 2025 decreases but would have done so in a budget neutral manner under our current regulations. Because section 1886(d)(5)(I) of the Act lacks any general budget neutrality requirement, we stated that we are not required by the statute to budget neutralize this transition policy. In some circumstances CMS has exer 6(d)(5)(I) of the Act lacks any general budget neutrality requirement, we stated that we are not required by the statute to budget neutralize this transition policy. In some circumstances CMS has exercised discretion under section 1886(d)(5)(I) of the Act twice over—first to adopt an exception or adjustment, and then again to make that exception and adjustment budget neutral.496 However, under the unique circumstances and due to the timing of the appellate court’s decision so close to the beginning of FY 2025, we stated that we did not deem it appropriate to provide a second exception or adjustment that would budget neutralize the transition policy we were establishing in that IFC. Unlike most policies relevant to the calculation of the hospital wage index, the timing of the court’s decision shortly before the beginning of the fiscal year necessitated swift action by the agency via an IFC, rather than providing for prior notice and opportunity for comment. We stated that the agency’s action in the FY 2025 IFC was intended to promote certainty regarding FY 2025 IPPS payments in light of the reasoning of Bridgeport and its application to the low wage index hospital policy in FY 2025, ction in the FY 2025 IFC was intended to promote certainty regarding FY 2025 IPPS payments in light of the reasoning of Bridgeport and its application to the low wage index hospital policy in FY 2025, which would create ongoing confusion for hospitals extending into FY 2025 about the amount of their IPPS payments and would constitute an inefficient use of agency resources. We stated that in this instance, the lack of an opportunity prior to the effective date for interested parties to comment on the transition policy weighs in favor of an approach that does not adversely affect the 496 For example, CMS has stated in the past that it would exercise its discretion under section 1886(d)(5)(I) of the Act to make the low wage index hospital policy budget neutral even if budget neutrality were not required by statute (88 FR 58979). significant majority of hospitals. Because section 1886(d)(5)(I) lacks any general budget neutrality requirement, we stated that we are not required by the statute to budget neutralize this transition policy. For these reasons, we declined to budget neutralize the transition policy in this case. Therefore, in the FY 2025 IFC, we used our authority under sectio e to budget neutralize this transition policy. For these reasons, we declined to budget neutralize the transition policy in this case. Therefore, in the FY 2025 IFC, we used our authority under section 1886(d)(5)(I)(i) of the Act to create a narrow transitional exception to the calculation of FY 2025 IPPS payments for low wage index hospitals significantly impacted by the removal of the low wage index hospital policy.497 498 The transitional exception policy established in that IFC applies to hospitals that benefitted from the FY 2024 low wage index hospital policy. For those hospitals, we compared the hospital’s FY 2025 wage index established in the FY 2025 IFC to the hospital’s FY 2024 wage index. If the hospital was significantly impacted by the removal of the low wage index hospital policy, meaning the hospital’s FY 2025 wage index established in the FY 2025 IFC decreased by more than 5 percent from the hospital’s FY 2024 wage index, then the transitional payment exception for FY 2025 for that hospital is equal to the additional FY 2025 amount the hospital would be paid under the IPPS if its FY 2025 wage index were equal to 95 percent of its FY 2024 wage index.499 For example, 025 for that hospital is equal to the additional FY 2025 amount the hospital would be paid under the IPPS if its FY 2025 wage index were equal to 95 percent of its FY 2024 wage index.499 For example, assume the FY 2024 wage index for a hospital that benefitted from the low wage index hospital policy was 0.7600, and the hospital’s FY 2025 wage index established in the FY 2025 IFC was 0.7100. The hospital’s FY 2025 wage index established in the FY 2025 IFC decreased by more than 5 percent from the hospital’s FY 2024 wage index [that is, 0.7100 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00652 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37187 the current wage index methodology or both. While a commenter stated that CMS was compelled to vacate the policy following the court ruling, this and other commenters described potential consequences of the policy ending, including hindered access to care, increased hospital closures, and recruitment challenges. Several commenters expressed specific concerns for rural hospitals with the rem uences of the policy ending, including hindered access to care, increased hospital closures, and recruitment challenges. Several commenters expressed specific concerns for rural hospitals with the removal of the low wage index hospital policy, noting that many rural hospitals will experience a lower wage index, which could lead to financial distress for rural hospitals and lack of access of care in rural areas. A commenter called for the FY 2025 IFC to be withdrawn and the removal of the low wage index hospital policy to be delayed. Response: We appreciate the commenters’ concerns regarding our recalculation of the FY 2025 wage index and removal of the low wage index hospital policy After considering the D.C. Circuit’s decision, we recalculated the IPPS hospital wage index to remove the low wage index hospital policy for FY 2025. As discussed earlier, consistent with our past practice, to mitigate the negative financial impacts for FY 2025, we established a transition policy for hospitals significantly impacted by the removal of the FY 2025 low wage index hospital policy using our authority under section 1886(d)(5)(I) of the Act. Comment: Some commenters supported increasing the wa als significantly impacted by the removal of the FY 2025 low wage index hospital policy using our authority under section 1886(d)(5)(I) of the Act. Comment: Some commenters supported increasing the wage index values of low wage hospitals but urged CMS to do so in a non-budget-neutral manner. Other commenters supported removal of the low wage index policy for FY 2025, with some recommending that CMS not implement the policy in the future. Response: We appreciate commenters’ support regarding the low wage index hospital policy. As discussed earlier, we recalculated the IPPS hospital wage index to remove the low wage index hospital policy for FY 2025 after considering the D.C. Circuit’s decision in Bridgeport Hosp. v. Becerra. For the reasons explained in the FY 2025 IFC, we declined to implement the transition policy for low wage index hospitals significantly impacted by the removal of the low wage index hospital policy in a budget neutral manner for FY 2025. Comment: Many commenters appreciated the transitional payment exception, with some commenters expressing concerns regarding the structure of the transition policy. While commenters supported the implementation of the transition reciated the transitional payment exception, with some commenters expressing concerns regarding the structure of the transition policy. While commenters supported the implementation of the transition policy in a non-budget neutral manner, many commenters called for other changes. Commenters suggested the transition policy should be extended beyond one year to give impacted hospitals time to adjust to the rescission of the policy, citing the short time period between the release of the FY 2025 IFC and the beginning of FY 2025. Other commenters stated that hospitals did not have a chance to prepare for the removal of the low wage hospital policy since it had been in place for four years and, per the FY 2025 IPPS/LTCH PPS final rule, was expected to be extended for at least three more years. Several commenters stated the transition policy should be based on the higher of the FY 2024 wage index or the FY 2025 wage index set forth the FY 2025 IPPS/LTCH PPS final rule, as corrected. Several commenters requested the transition be expanded to apply to more hospitals beyond those that will realize a more than 5 percent decrease in their wage index values. Response: In the past, we establish commenters requested the transition be expanded to apply to more hospitals beyond those that will realize a more than 5 percent decrease in their wage index values. Response: In the past, we established temporary transition policies when there have been significant changes to payment policies, and we have limited the duration of each transition in order to phase in the effects of those payment policy changes. For the reasons explained earlier, we established a transition policy for FY 2025 low wage index hospitals significantly impacted by the removal of the low wage index hospital policy. For those hospitals, the transitional exception to the calculation of FY 2025 IPPS payments is based on whether the hospital’s FY 2025 wage index established in the FY 2025 IFC decreased by more than 5 percent from the hospital’s FY 2024 wage index. This comparison operates similarly to the wage index cap policy at 42 CFR 412.64(h)(7), which applies a 5-percent cap on any decrease to a hospital’s wage index from its wage index in the prior FY in a budget neutral manner. Given the unique circumstances due to the timing of the appellate court’s decision so close to the beginning of FY 2025, the tra e index from its wage index in the prior FY in a budget neutral manner. Given the unique circumstances due to the timing of the appellate court’s decision so close to the beginning of FY 2025, the transitional adjustment established in the FY 2025 IFC was implemented in a non- budget neutral manner. Regarding FY 2026, we note elsewhere in this final rule, we are finalizing as proposed a transitional policy for hospitals that benefitted from the FY 2024 low wage index hospital policy that compares the hospital’s FY 2026 wage index to the hospital’s FY 2024 wage index that is being implemented in a budget neutral manner through an adjustment applied to the standardized amount for all hospitals. For a more detailed discussion of the FY 2026 transition policy, we refer readers to section III.F.7. of the preamble of this final rule. We note that we received comments that were out of scope with regard to the provisions of the FY 2025 IFC. Therefore, we are not responding to these comments in this final rule. After consideration of the public comments received, in this final rule, we are finalizing without modification the revised IPPS wage index values for FY 2025 after removal of the lo this final rule. After consideration of the public comments received, in this final rule, we are finalizing without modification the revised IPPS wage index values for FY 2025 after removal of the low wage index hospital policy, the removal of the low wage index budget neutrality factor from the FY 2025 standardized amounts, and the transitional payment exception for low wage index hospitals significantly impacted by the removal of the low wage index hospital policy for FY 2025 under our authority under section 1886(d)(5)(I)(i) of the Act. In addition, we are finalizing without modification that this transition policy is not implemented in a budget neutral manner for FY 2025. Lastly, we note we received no comments specific to the non-budget neutral equivalent exception under the capital IPPS and are finalizing without modification. c. Changes to Prospective Payment Rates for Hospital Inpatient Operating Costs for Acute Care Hospitals for FY 2025 To reflect the removal of the low wage index hospital policy for FY 2025 following the appellate court decision in Bridgeport Hosp. v. Becerra, in the FY 2025 IFC (89 FR 80408 through 80411), we made changes to certain FY 2025 IPPS operat index hospital policy for FY 2025 following the appellate court decision in Bridgeport Hosp. v. Becerra, in the FY 2025 IFC (89 FR 80408 through 80411), we made changes to certain FY 2025 IPPS operating rates and factors due to implementation of the revised FY 2025 wage index and transitional payment exception for low wage index hospitals significantly impacted by the removal of the low wage index hospital policy. We present a summary of these changes in the discussion that follows. For additional details, we refer readers to the FY 2025 IFC (89 FR 80408 through 80411). As discussed later in this section, we did not receive any comments on these changes and are finalizing them without modification. (1) Calculation of the Adjusted Standardized Amount for FY 2025 In the FY 2025 IFC (89 FR 80409), we discussed that based on the order of our FY 2025 budget neutrality calculations, the removal of the low wage index hospital policy and application of the transitional exception policy did not impact the calculation of the first five budget neutrality factors (that is, MS– DRG Reclassification and Recalibration Budget Neutrality Factor, Cap Policy MS–DRG Weights Budget Neutrality Factor, t impact the calculation of the first five budget neutrality factors (that is, MS– DRG Reclassification and Recalibration Budget Neutrality Factor, Cap Policy MS–DRG Weights Budget Neutrality Factor, Wage Index Budget Neutrality Factor, Reclassification Budget Neutrality Factor, and the Rural Floor Budget Neutrality Factor). (We also VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00653 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37188 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations noted that the Rural Floor Budget Neutrality Factor is applied to the national wage indexes while the other budget neutrality adjustments are applied to the standardized amounts.) Under the provisions of the FY 2025 IFC, we no longer made a budget neutrality adjustment to the standardized amount for the low wage index hospital policy. Accordingly, in the FY 2025 IFC, we recalculated the cap policy for wage index budget neutrality factor and rural demonstration budget neutrality factor used for determining the standardized amounts for FY 2025 (89 FR 80409). We also calculated the FY 2025 policy for wage index budget neutrality factor and rural demonstration budget neutrality factor used for determining the standardized amounts for FY 2025 (89 FR 80409). We also calculated the FY 2025 outlier threshold to reflect the provisions of the FY 2025 IFC along with changes to those budget neutrality factors (89 FR 80409 through 80410). In addition, we updated the calculation of Factor 3 of the uncompensated care payment methodology for all DSH-eligible hospitals to reflect the updated information for the hospitals that are no longer projected to receive interim uncompensated care payments for FY 2025, revised the amount of the total uncompensated care payment calculated for each DSH-eligible hospital, and updated the list that we published for the FY 2025 IPPS/LTCH PPS final rule, as corrected, of hospitals that we identified to be subsection (d) hospitals and subsection (d) Puerto Rico hospitals projected to be eligible to receive interim uncompensated care payments for FY 2025 (see the discussion of Table 18 in the FY 2025 IFC (89 FR 80413 through 80414)). In the FY 2025 IFC (89 FR 80409), we discussed that, because we applied the transitional exception for certain hospi 25 (see the discussion of Table 18 in the FY 2025 IFC (89 FR 80413 through 80414)). In the FY 2025 IFC (89 FR 80409), we discussed that, because we applied the transitional exception for certain hospitals that benefitted from the low wage index hospital policy adjustment in a non-budget neutral manner, we first determined which hospitals would be eligible for this transition policy (that is, identified those that had received a higher wage index under the low wage index hospital policy in FY 2024). We then applied the transitional payment exception for eligible hospitals as described in section II.A. of the FY 2025 IFC. (As stated previously, hospitals eligible for the new transitional exception policy for FY 2025 are excepted from the wage index cap policy at 42 CFR 412.64(h)(7), which is budget neutral by design.) The FY 2025 budget neutrality factors that we recalculated in the FY 2025 IFC were calculated using data described in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69941 through 69948), with the FY 2025 IPPS/LTCH PPS final rule correction. In the FY 2025 IFC (89 FR 80409), we calculated a budget neutrality factor for the wage index cap policy at 42 CFR 412.64(h)(7) of 0.9 ugh 69948), with the FY 2025 IPPS/LTCH PPS final rule correction. In the FY 2025 IFC (89 FR 80409), we calculated a budget neutrality factor for the wage index cap policy at 42 CFR 412.64(h)(7) of 0.999166 in accordance with the existing methodology. As noted earlier, hospitals that are eligible for the transitional exception policy are excepted from the wage index cap policy at 42 CFR 412.64(h)(7) in FY 2025. (For additional details on the calculation of the wage index cap budget neutrality adjustment factor for FY 2025, refer to the FY 2025 IFC (89 FR 80409).) In the FY 2025 IFC (89 FR 80409), we recalculated the budget neutrality factor for the rural community hospital demonstration program using the methodology described in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69947 through 69948). However, when rounded to the sixth decimal, the factor (0.999811) did not change from the corrected factor as set forth in the FY 2025 IPPS/LTCH PPS correction. The standardized amounts set forth in Tables 1A, 1B, and 1C for FY 2025 listed and published in section IV. of the FY 2025 IFC (89 FR 80414) (and available via the internet on the CMS website) reflect these factors. We received no comm in Tables 1A, 1B, and 1C for FY 2025 listed and published in section IV. of the FY 2025 IFC (89 FR 80414) (and available via the internet on the CMS website) reflect these factors. We received no comments on the FY 2025 budget neutrality calculations and factors established in the FY 2025 IFC and are finalizing them in this final rule without modification. (2) Outlier Payments To calculate the FY 2025 outlier fixed-loss amount that reflects the provisions of the FY 2025 IFC, we used the methodology (data, factors, etc.) as described in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69948 through 66962), as corrected, in conjunction with the wage index values, transitional payment exception policy for the removal of the low wage index hospital policy and other rates and factors established in the FY 2025 IFC (described previously). In the FY 2025 IFC (89 FR 80410), we determined a threshold of $46,217 for FY 2025 and calculated total outlier payments of $4,354,709,696 and total operating Federal payments of $80,366,934,481. (For additional details on the outlier methodology and calculations for FY 2025, refer to the FY 2025 IFC (89 FR 80409 through 80410).) Accordingly, in that FY 2025 ederal payments of $80,366,934,481. (For additional details on the outlier methodology and calculations for FY 2025, refer to the FY 2025 IFC (89 FR 80409 through 80410).) Accordingly, in that FY 2025 IFC, we established that for FY 2025, the outlier fixed-loss cost threshold is equal to the prospective payment rate for the MS– DRG, plus any IME, empirically justified Medicare DSH payments, estimated uncompensated care payment, estimated supplemental payment for eligible Indian Health Service (IHS)/ Tribal hospitals and Puerto Rico hospitals, and any add on payments for new technology, plus $46,217. In addition, in the FY 2025 IFC, we applied an outlier adjustment factor of 0.949 to the operating standardized amount based on the FY 2025 outlier threshold (as established in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69961)). In the FY 2025 IFC (89 FR 80410), we discussed that we establish an outlier threshold that is applicable to both hospital inpatient operating costs and hospital inpatient capital-related costs. When we modeled the combined operating and capital outlier payments, we found that using a common threshold resulted in a higher percentage of outlier payments for capit patient capital-related costs. When we modeled the combined operating and capital outlier payments, we found that using a common threshold resulted in a higher percentage of outlier payments for capital-related costs than for operating costs. In the FY 2025 IFC, we projected that the threshold for FY 2025 (which reflects our methodology to incorporate an estimate of operating outlier reconciliation (see 89 FR 69948 through 69953) would result in outlier payments that would equal 5.1 percent of operating DRG payments and we estimated that capital outlier payments would equal 4.23 percent of capital payments based on the capital Federal rate established in section II.C. of the FY 2025 IFC (and which reflects our methodology to incorporate an estimate of capital outlier reconciliation as discussed in the FY 2025 IPPS/LTCH PPS final rule (see 89 FR 69953 through 69955)). The outlier adjustment factors applied to the operating standardized amount and capital Federal rate based on the FY 2025 outlier threshold established in the FY 2025 IFC are as follows: VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00654 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D 5 outlier threshold established in the FY 2025 IFC are as follows: VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00654 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37189 As described in the FY 2025 IFC (89 FR 80410), we applied the outlier adjustment factors to the FY 2025 payment rates after removing the effects of the FY 2024 outlier adjustment factors on the standardized amount. We received no comments on the FY 2025 outlier calculations and factors established in the FY 2025 IFC and are finalizing them in this final rule without modification. (3) FY 2025 Standardized Amounts Tables 1A and 1B listed and published in section IV. of the FY 2025 IFC (and available via the internet on the CMS website) contain the national standardized amounts that apply to all hospitals, except hospitals located in Puerto Rico, for FY 2025. The standardized amount for hospitals in Puerto Rico is shown in Table 1C listed and published in section IV. of the FY 2025 IFC (and available via the internet on the CMS website). We also provide 5. The standardized amount for hospitals in Puerto Rico is shown in Table 1C listed and published in section IV. of the FY 2025 IFC (and available via the internet on the CMS website). We also provided a table that illustrates the changes from the FY 2024 national standardized amounts to the FY 2025 national standardized amounts. (See 89 FR 80410 through 80411) We received no comments on the FY 2025 standardized amounts established in the FY 2025 IFC and are finalizing them in this final rule without modification. As noted previously, the standardized amounts are set forth in Tables 1A, 1B, and 1C for FY 2025 listed and published in section IV. of the FY 2025 IFC (89 FR 80414) (and available via the internet on the CMS website). d. Payment Rates for Acute Care Hospital Inpatient Capital-Related Costs for FY 2025 Similar to the discussion of the operating IPPS payment rates previously, the removal of the low wage index hospital policy and the establishment of a transitional exception policy in the FY 2025 IFC impacts the calculation of certain budget neutrality adjustment factors used for determining the capital Federal rate for FY 2025. As discussed previously, we also calculated t licy in the FY 2025 IFC impacts the calculation of certain budget neutrality adjustment factors used for determining the capital Federal rate for FY 2025. As discussed previously, we also calculated the FY 2025 outlier threshold to reflect the provisions of that IFC along with the corresponding changes to the IPPS payment rates. Accordingly, in the FY 2025 IFC (89 FR 80411 through 80412), we established the following factors used for determining the capital Federal rate for FY 2025: • The outlier payment adjustment factor. • The portion of the budget neutrality adjustment factor for changes in the geographic adjustment factor (GAF) for the 5-percent cap on wage index decreases policy. (Under the provisions of the FY 2025 IFC, this factor would no longer reflect the low wage index hospital policy.) In the FY 2025 IFC we discussed that, in general, these factors were calculated using the data and calculation methodology described in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69968 through 69971) with the FY 2025 IPPS/ LTCH PPS final rule correction, except for the methodology for calculating the GAF budget neutrality factor which we modified to reflect the provisions of the IFC. We gh 69971) with the FY 2025 IPPS/ LTCH PPS final rule correction, except for the methodology for calculating the GAF budget neutrality factor which we modified to reflect the provisions of the IFC. We present a summary of these changes in the discussion that follows. For additional details, we refer readers to the FY 2025 IFC (89 FR 80411 through 80412). As discussed later in this section, we did not receive any comments on these changes and are finalizing them without modification. (1) Outlier Payment Adjustment Factor A shared threshold is used to identify outlier cases for both inpatient operating and inpatient capital-related payments. In the FY 2025 IFC (89 FR 80411), we stated that based on the threshold discussed in section II.B. of that IFC, we estimated that prior to taking into account projected capital outlier reconciliation payments, outlier payments for capital-related costs will equal 4.26 percent of inpatient capital- related payments based on the capital Federal rate in FY 2025. We also stated that we estimate that taking into account projected capital outlier reconciliation payments will decrease the estimated percentage of FY 2025 capital outlier payments by 0.03 p FY 2025. We also stated that we estimate that taking into account projected capital outlier reconciliation payments will decrease the estimated percentage of FY 2025 capital outlier payments by 0.03 percent (as discussed in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69968). Therefore, accounting for estimated capital outlier reconciliation, the estimated outlier payments for capital-related PPS payments will equal 4.23 percent (4.26 percent¥0.03 percent) of inpatient capital-related payments based on the capital Federal rate in FY 2025. Accordingly, in the FY 2025 IFC (89 FR 80411), we applied an outlier adjustment factor of 0.9577 in determining the capital Federal rate for FY 2025. As we noted in the FY 2025 IFC, although the unrounded FY 2025 outlier adjustment factor was revised because of the removal of the low wage index hospital policy and transitional payment exception, after rounding this factor to 4 decimal places, the rounded factor was unchanged from the final rule. We received no comments on the FY 2025 outlier adjustment factor established in the FY 2025 IFC and are finalizing it in this final rule without modification. (2) Budget Neutrality Adjustment Factor for Cha eived no comments on the FY 2025 outlier adjustment factor established in the FY 2025 IFC and are finalizing it in this final rule without modification. (2) Budget Neutrality Adjustment Factor for Changes in the GAF The capital Federal rate is adjusted so that aggregate payments for the fiscal year based on the capital Federal rate, after any changes resulting from the annual DRG reclassification and recalibration and changes in the GAF, are projected to equal aggregate payments that would have been made on the basis of the capital Federal rate without such changes. In the FY 2025 IFC (89 FR 80412), we discussed that for FY 2025 we use a 2-step methodology for computing the budget neutrality factor for changes in the GAFs in light of the effect of wage index changes on the GAFs. In the first step, we first calculate a factor to ensure budget neutrality for changes to the GAFs due to the update to the wage data, wage index reclassifications and redesignations, and application of the rural floor policy, consistent with our historical GAF budget neutrality factor methodology. In the FY 2025 IFC, we stated that the provisions of the IFC did not impact this budget neutrality factor (0.9 al floor policy, consistent with our historical GAF budget neutrality factor methodology. In the FY 2025 IFC, we stated that the provisions of the IFC did not impact this budget neutrality factor (0.9884). We also stated that the incremental adjustment factor for the FY 2025 MS–DRG reclassification and recalibration and for changes in the FY 2025 GAFs due to the update to the wage data, wage index reclassifications and redesignations, and application of the rural floor policy of 0.9854 is not impacted by the provisions of the FY 2025 IFC (89 FR 80412). Due to the removal of the low wage index hospital policy (discussed previously and also referred to as the lowest quartile hospital wage index adjustment in the discussion of the 2- step methodology in the FY 2025 IPPS/ VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00655 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k / > H P G 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00656 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k / > H P G 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00657 001 PO 00000 Frm 00656 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k / > H P G 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00657 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37192 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations the Hybrid Hospital-Wide Readmission (HWR) measure beginning with the FY 2028 payment determination, associated with a July 1, 2025–June 30, 2026, performance period; and the Hybrid Hospital-Wide Mortality (HWM) measure beginning with the FY 2028 payment determination, associated with a July 1, 2025–June 30, 2026, performance period. These policies will not affect information collection burden. We are removing four measures beginning with the CY 2024 reporting period/FY 2026 payment determination: (1) the Hospital Commitment to Health Equity measure; (2) the COVID–19 Vaccination Coverage among Healthcare Personnel (HCP) measure; (3) the Screening for Social Drivers of Health measure; and (4) the Screen Positive Rate for Social Drivers of Health Measure. We discuss the impacts on info among Healthcare Personnel (HCP) measure; (3) the Screening for Social Drivers of Health measure; and (4) the Screen Positive Rate for Social Drivers of Health Measure. We discuss the impacts on information collection burden associated with these policies later in this section. Using the most recent data from the BLS for medical records specialists (SOC 29–2072), entitled, the May 2023 National Occupational Employment and Wage Estimates (OEWS), we are finalizing the use of the mean hourly wage for medical records specialists for the industry, ‘‘general medical and surgical hospitals,’’ which is $27.69.500 We believe the industry of ‘‘general medical and surgical hospitals’’ is more specific to this program compared to other industries under medical records specialists, such as ‘‘office of physicians’’ or ‘‘nursing care facilities.’’ We calculated the cost of overhead, including fringe benefits, at 100 percent of the mean hourly wage, consistent with previous years. This is necessarily a rough adjustment, both because fringe benefits and overhead costs vary significantly by employer and methods of estimating these costs vary widely in the literature. Nonetheless, we believe that do a rough adjustment, both because fringe benefits and overhead costs vary significantly by employer and methods of estimating these costs vary widely in the literature. Nonetheless, we believe that doubling the hourly wage rate ($27.69 × 2 = $55.38) to estimate total cost is a reasonably accurate estimation method. Unless otherwise specified, we will calculate cost burden to hospitals using a wage plus benefits estimate of $55.38 per hour throughout the discussion in this section of this final rule for the Hospital IQR Program. In the FY 2025 IPPS/LTCH PPS final rule (89 FR 69894), our burden estimates were based on an assumption of approximately 3,050 IPPS hospitals. For this final rule, based on data from the FY 2025 Hospital IQR Program 500 U.S. Bureau of Labor Statistics. Occupational Outlook Handbook, Medical Records Specialists. Accessed November 27, 2024. Available at: https:// www.bls.gov/oes/current/oes292072.htm. payment determination, we are maintaining that assumption and estimate that approximately 3,050 IPPS hospitals will report data to the Hospital IQR Program for the CY 2026 reporting period. b. Information Collection Burden Estimate for the Modifications to the Ho stimate that approximately 3,050 IPPS hospitals will report data to the Hospital IQR Program for the CY 2026 reporting period. b. Information Collection Burden Estimate for the Modifications to the Hospital-Level, RSCR Following Elective Primary THA/TKA Measure and Hospital 30-Day, All-Cause, RSMR Following Acute Ischemic Stroke Hospitalization Measure Beginning With the FY 2027 Payment Determination In sections X.C.3.a. and X.C.3.b. of the preamble of this final rule, we discuss the modification of the COMP–HIP– KNEE measure beginning with the FY 2027 payment determination, associated with the April 1, 2023–March 31, 2025 performance period and the MORT–30– STK measure beginning with the FY 2027 payment determination, associated with the July 1, 2023–June 30, 2025 performance period. These modifications will include adding MA patients to the current cohort of patients and shortening the performance period from 3 years to 2 years. Because these measures will be calculated using MA encounter data and Medicare FFS claims that are already reported to the Medicare program for payment purposes, modifying these measures does not result in a change in burden associated with OMB control nu unter data and Medicare FFS claims that are already reported to the Medicare program for payment purposes, modifying these measures does not result in a change in burden associated with OMB control number 0938–1022. c. Information Collection Burden Estimate for the Modification of the Hybrid HWR and HWM Measures Beginning With the FY 2028 Payment Determination In section X.C.7.c. of the preamble of this final rule, we are modifying the Hybrid HWR and HWM measure reporting requirements beginning with the FY 2028 payment determination, associated with a July 1, 2025–June 30, 2026, performance period. This modification will lower the submission thresholds for both the Hybrid HWR and HWM measures to allow for up to two missing laboratory results and up to two missing vital signs, reduce the core clinical data elements (CCDEs) submission requirement to 70 percent or more of discharges, and reduce the submission requirement of linking variables to 70 percent or more of discharges. In the CY 2025 OPPS/ASC final rule (89 FR 94495 through 94499), we finalized that submission of CCDEs and linking variables associated with the Hybrid HWR and Hybrid HWM measures will remain voluntary. In the F 2025 OPPS/ASC final rule (89 FR 94495 through 94499), we finalized that submission of CCDEs and linking variables associated with the Hybrid HWR and Hybrid HWM measures will remain voluntary. In the FY 2020 IPPS/LTCH PPS and FY 2022 IPPS/LTCH PPS final rules, respectively, we estimated the burden for voluntary reporting for the Hybrid HWR (84 FR 42603 and 42604) and Hybrid HWM measures (86 FR 45508) and stated that we encourage all hospitals to submit data for the Hybrid HWR and Hybrid HWM measures during the voluntary reporting period. As a result, our previously finalized reporting burden estimates assume that all hospitals will participate in order to not underestimate the burden on participating hospitals and account for the submission of CCDEs and linking variables. Therefore, while these modifications are designed to reduce the administrative burden associated with reporting these measures, they will not affect information collection burden as neither the amount of data collected nor frequency of data submission are impacted. d. Information Collection Burden Estimate for the Removal of the Hospital Commitment to Health Equity Measure Beginning With the CY 2024 Reporting Perio nor frequency of data submission are impacted. d. Information Collection Burden Estimate for the Removal of the Hospital Commitment to Health Equity Measure Beginning With the CY 2024 Reporting Period/FY 2026 Payment Determination In section X.C.4.a. of the preamble of this final rule, we are removing the Hospital Commitment to Health Equity (HCHE) measure beginning with the CY 2024 reporting period/FY 2026 payment determination. Reporting on the HCHE measure involves each hospital being required to provide responses and attest ‘‘yes’’ or ‘‘no’’ in response to as many as five questions one time per year for a given reporting period through CMS’ HQR System. We estimate each hospital requires 10 minutes (0.167 hours) annually to report this measure. The current burden estimate approved under OMB control number 0938–1022 is 509 hours annually across all 3,050 IPPS hospitals (0.167 hours × 3,050 IPPS hospitals). Therefore, we estimated the removal of this measure will decrease the burden for all 3,050 IPPS hospitals by 509 hours annually at a savings of $28,188 (509 hours × $55.38). e. Information Collection Burden Estimate for the Removal of the COVID– 19 Vaccination Coverage Among H for all 3,050 IPPS hospitals by 509 hours annually at a savings of $28,188 (509 hours × $55.38). e. Information Collection Burden Estimate for the Removal of the COVID– 19 Vaccination Coverage Among HCP Measure Beginning With the CY 2024 Reporting Period/FY 2026 Payment Determination In section X.C.4.b. of the preamble of this final rule, we are removing the COVID–19 Vaccination Coverage among HCP measure beginning with the CY 2024 reporting period/FY 2026 payment determination. This measure was previously finalized in the FY 2022 IPPS/LTCH PPS final rule (86 FR 45374 through 45382), and the associated VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00658 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37193 information collection is approved under OMB control number 0920– 1317 501 (expiration date January 31, 2028). Hospitals have the option to manually enter data directly into the Centers for Disease Control and Prevention (CDC) National Healthcare Safety Network (NHSN) web-based application or by uploading a CSV file.