Transparency in Coverage

The Departments proposed to require, in new 26 CFR 54.9815- 2715A3(b)(2)(i), 29 CFR 2590.715-2715A3(b)(2)(i), and 45 CFR 147.212(b)(2)(i), that plans and issuers must make available, in a machine-readable format, a Change-log File for each In-network Rate File, that identifies any changes made to the required information in the In-network Rate File since the immediately preceding published In- network Rate File. The proposed Change-log File would be required to be publicly posted in the form as specified in guidance issued by the Departments, consistent with redesignated and amended paragraph (b)(3) and discussed in section III.C.9. of the proposed rules. It would be required to be posted in accordance with the timing requirements proposed at redesignated paragraph (b)(4)(iii) and discussed in section III.C.10. of the proposed rules. Specifically, it would be required to be posted on the first day of the calendar-year quarter following the date on which the first In-network Rate File would be required to be posted under proposed paragraph (b)(4)(i).\81\ The purpose of the proposed Change-log File would be to assist all file users in identifying changes to the required information in the In-network Rate File from one reporting period to the next. Pursuant to the proposed requirement to publish the In-network Rate File described at paragraph (b)(1)(i) quarterly, the updated Change-log File would also be required to be published quarterly, indicating whether or not there were changes compared to the previously published Change-log File. The Departments sought comment on whether to require a Change-log File and how to structure an effective Change-log File, including the preferred machine-readable format and which specific data elements should be required. The Departments also requested comment on whether the file should simply identify which information changed between reporting periods or additionally indicate how that information changed. Further, the Departments asked whether certain types of data changes should be excluded to maximize the usefulness of the reporting, and invited comment on the specific burdens plans and issuers would face for the different possibilities for a Change-log File.

\81\ See Table 2 for an example.

After consideration of public comments, the Departments are not finalizing the requirement for plans and issuers to make available a Change-log File for each In-network Rate File.

Many commenters supported the proposal to require a Change-log File noting that it would improve the usability of the In-network Rate File and would make it easier to derive meaningful insights from spending, cost trends, and utilization. Commenters also pointed out that the Change-log File would reduce the administrative and financial burden for file users by creating a simple way to monitor updates in the relevant parts of massive datasets.

The Departments recognize the efficiencies a Change-log File could create for file users. The Departments also agree that the Change-log File may reduce the burden for file users. However, as discussed in more detail later in this section, it would create significant burden for plans and issuers to create and maintain the files. Furthermore, the Departments have determined that the other In-network Rate File requirements, as amended by these final rules, should reduce administrative burden to increase file accessibility thereby achieving some of the intended goals of the Change-log File.

A few commenters offered suggestions for how to implement the Change-log File requirement. A commenter recommended addressing the Change-log File requirements through technical implementation guidance rather than regulation to allow greater flexibility as the file evolves. Another commenter recommended the Departments provide clear and detailed requirements to ensure the Change-log File is useful, or alternatively, require plans and issuers to retain their files for 7 years so file users can compare versions themselves. Finally, a commenter recommended that the Departments develop a standardized template, informed by interested parties and users, to ensure consistency across plans and issuers and make Change-log outputs easier for users to navigate.

Many commenters recommended specific information or technical methodologies for the Change-log File or sought clarification on what information or formats would be required. A few commenters recommended that the Departments require plans and issuers to identify only the information that has changed, while others recommended that the Change- log File identify both the information that has changed and how it has changed. A few commenters recommended the Departments limit changes to provider participation and rate changes and to note them as “Added/ Changed/Removed,” rather than a redline style comparison from one file to the next. A few commenters recommended that the Departments narrowly define what constitutes as a “change” and to exclude minor or non- substantive changes. Additionally, a few commenters recommended the required data to be captured at the provider-rate level rather than the plan level. Finally, a commenter recommended that the Change-log File should be limited to requiring plans and issuers to publicize which version of schema is being used for their In-network Rate File and to modify their Change-log File whenever the schema changes.

The Departments acknowledge the requests for additional technical details on creating a Change-log file. However, because the Departments are not finalizing the requirement to publish a Change-log File for the reasons discussed later in this section, such additional details are not necessary.

Many commenters did not support requiring plans and issuers to publish and update a Change-log File. These commenters largely noted that the burden of creating and maintaining these files outweighs the marginal value they would provide to file users. A few commenters further explained the operational complexities and burden that smaller and rural non-profit plans with limited resources would face if this requirement was finalized. A few commenters were concerned about how

any Change-log File would be audited for completeness and accuracy. A few commenters also pointed out that the information that would be shared in the Change-log File can already be found by comparing In- network Rate Files, with a commenter noting that other proposed provisions would reduce In-network Rate File size, which would make comparisons between files easier, preempting the need for an entirely new file to discern changes between subsequent In-network Rate Files.

The Departments understand commenters' concerns that creating and maintaining a Change-log File would be operationally complex and create burden for plans and issuers. The Departments agree that the information a Change-log File would capture can already be identified by comparing In-network Rate Files. Given that the provisions finalized in this rule reduce the size of the In-network Rate Files, the Departments agree with commenters that it will be easier for file users to track changes across In-network Rate Files over time. In particular, reducing the reporting frequency of the In-network Rate File, as described in section III.C.11. of this preamble, lowers storage, hosting, bandwidth, and maintenance costs while giving users more time to work with each updated In-network Rate File. Also, limiting the In- network Rate File to likely provider-rate combinations, as described in section III.C.5. of this preamble, substantially shrinks file size and eases processing demands. Additionally, organizing files at the provider network level, as described in section III.C.1. of this preamble, further reduces duplication and file volume, making the data much easier to download, store, and analyze while improving consistency and comparability across networks, specialties, and geographic areas. These provisions combined will significantly improve user experience, reduce time and processing effort, and make the files more accessible, rendering a Change-log File duplicative for tracking updates. b. Utilization File

The Departments proposed to require at new paragraphs 26 CFR 54.9815-2715A3(b)(2)(ii), 29 CFR 2590.715-2715A3(b)(2)(ii), and 45 CFR 147.212(b)(2)(ii), that plans and issuers must make available in a machine-readable format an annual Utilization File for each In-network Rate File specified under paragraph (b)(1)(i), that includes, for the 12-month period that ends 6 months prior to the publication of each Utilization File: items and services covered under the plans or policies included in the files prepared as specified in proposed amended paragraph (b)(1)(i) for which a claim has been submitted and reimbursed, in whole or in part, and each in-network provider identified by the NPI, TIN, and Place of Service Code who was reimbursed, in whole or in part, for a claim for each covered item or service included, as specified in proposed paragraph (b)(2)(ii)(A) of this section. Plans and issuers would not be required to disclose the number of times that any given provider submitted a claim for any particular item or service, but rather only that a given provider submitted and was reimbursed, partially or in whole, for at least one claim for a covered item or service during the reporting period. The Utilization File would be required to be published in the form and manner specified in proposed redesignated paragraph (b)(3) and discussed in section III.C.9. of the proposed rule. Plans and issuers would be required to update and post the Utilization File in accordance with the timing requirements proposed at redesignated paragraph (b)(4)(iii) and discussed in section III.C.10. of the proposed rule. The Departments requested comments on this proposal. After consideration of public comments, the Departments are finalizing this requirement with two modifications: first, clarifying that claims that would be reimbursed but for cost-sharing liability must also be included when accounting for claims that were submitted and reimbursed; second, the lookback period to be for the most recent plan year (in the individual market, policy year) that ends at least 6 months prior to the date the Utilization File is made available as specified in paragraph (b)(4)(iii) instead of for the 12-month period that ends 6 months prior to the publication of each Utilization File. The Departments also amend this section to further redesignate this paragraph as paragraph (b)(2)(i).

Many commenters supported the proposal for a Utilization File, emphasizing that it would help file users differentiate between theoretical provider-service combinations and provider-service combinations that actually occur through paid claims. Several of these commenters added that the Utilization File would help with analyzing network adequacy (for example, self-insured plan sponsors who want to see which in-network providers are being utilized), accurate benchmarking of negotiated rates, and validating the information in the In-network Rate File. A few commenters agreed that use of NPI, TIN, and Place of Service Code in the Utilization File is appropriate for identifying providers and rates. A few commenters agreed that the Departments' proposal for a binary indicator of utilization, in which the Utilization File reflects only items and services and in-network providers for which at least one claim has been submitted and reimbursed, is sufficient to distinguish active provider-rate combinations.

The Departments agree with the commenters who identified that the value of the Utilization File is in elucidating which negotiated rates and services are being used in practice and making the overall Transparency in Coverage data disclosures more actionable. The Departments also agree that the privacy concerns from potentially identifying individual patients and the potential burden on plans and issuers to publish a larger volume of information are balanced through a binary indicator of utilization, which still protects against identifying individuals and requires less information to be published.

A few commenters encouraged the Departments to structure and describe the Utilization File in a manner that minimizes the risk of misinterpretation and clearly distinguishes historical claims activity from broader assessments of network adequacy or access to care. Another commenter encouraged the Departments to clearly articulate the intended purpose and limitations of the Utilization File so that employer plan sponsors and other interested parties understand how the data should, and should not, be used. A commenter requested that the Departments consider allowing issuers with multiple participating plans to satisfy the Utilization File requirement through a centrally produced file rather than requiring each individual plan to publish duplicative records for the same service.

The Departments appreciate commenters' feedback. The Departments will include feedback on the structure and limitations of the Utilization File through the future technical implementation guidance process on GitHub to help file producers. The purpose of the Utilization File is to identify which negotiated rates and services are being used, and to act as a check on the unlikely provider-rate combinations that plans and issuers are excluding. While the main purpose of the Utilization File is not to identify network adequacy, it can provide some information that would allow employer plan sponsors and other interested parties to better understand provider

service patterns and whether networks in specific geographic areas have larger pools of providers performing certain procedures. The Departments also reiterate that plans and issuers must publish a Utilization File for each In-network Rate File, organized at the provider-network level, as described in section III.C.1. of this preamble, which should help reduce duplication from plans that share provider networks.

A commenter recommended that the Departments require plans and issuers to include the median allowed amount per service in the Utilization File to help researchers rectify instances where a Hospital Price Transparency machine-readable file entry does not match a Transparency in Coverage machine-readable file entry. Another commenter added that the Departments should require further specificity for professional claims by requiring NPIs at the Type 1 level for the Rendering/Servicing provider and require disclosure of the service facility location information (Box 32 on the CMS-1500 claim form). A commenter requested clarification on what counts as a “claim that has been submitted and reimbursed, in whole or in part,” in situations where a provider performs a service and submits a claim which the plan or issuer does not pay because the consumer has not met their deductible.

The Departments do not agree with requiring plans and issuers to include the median allowed amount per service in the Utilization File because the Utilization File is meant to serve as a check on the excluded unlikely provider-rate combinations in the In-network Rate File, rather than to provide additional data disclosures. Also, the Departments clarify at 26 CFR 54.9815-2715A3(b)(2)(i)(A) and (B), 29 CFR 2590.715-2715A3(b)(2)(i)(A) and (B), and 45 CFR 147.212(b)(2)(i)(A) and (B) that plans and issuers should include claims from in-network providers for covered items and services that have been submitted but for which the plan or issuer does not pay because the participant, beneficiary, or enrollee has a cost-sharing liability, such as an unmet deductible, given that the plan or issuer would have reimbursed the provider and the claim would otherwise meet the standards for inclusion in the Utilization File but for the cost-sharing liability. The Departments will clarify the required NPI type in technical implementation guidance through sample schemas on GitHub.

A commenter recommended that the Departments require access to the Utilization File through Application Programming Interfaces (APIs).

The Departments recognize the benefits of API access to large volumes of information, but as discussed in section III.C.9. of this preamble, the Departments are not requiring the use of APIs at this time due to the substantial new development costs it would place on plans and issuers and the effectiveness of delivering the required information through the modified and redesignated file format requirements at 26 CFR 54.9815-2715A3(b)(3)(i), 29 CFR 2590.715- 2715A3(b)(3)(i), and 45 CFR 147.212(b)(3)(i), which will increase file format standardization and improve accessibility.

A commenter noted that, if the internet-based self-service tool returned a result with a provider who has no reported volume for a specific code, a participant, beneficiary, or enrollee may be confused about whether the provider is active or available.

The 2020 final rules did not require, and the proposed rules did not propose, that plans and issuers use the data in the machine- readable files to generate cost-sharing estimates for the internet- based self-service tool. If a plan or issuer chooses to do so, they are still obligated to ensure that information required to be disclosed to participants, beneficiaries, and enrollees under 26 CFR 54.9815- 2715A2(b)(1), 29 CFR 2590.715-2715A2(b)(1), and 45 CFR 147.211(b)(1) remains accurate at the time the request is made, with respect to a participant's, beneficiary's, or enrollee's cost-sharing liability for covered items and services, regardless of finalized changes to the In- network Rate File and Allowed Amount File in these final rules.

Many commenters opposed the proposal for a Utilization File, citing significant burden to create a new file that includes claims data from a separate system. Commenters also stated it would increase the overall size of data disclosures and duplicate existing claims reporting requirements. These commenters further indicated that the file would include no pricing or rate information and would be of limited use to consumers and regulators. Many commenters also cited privacy concerns from the possibility of identifying patients who are obtaining sensitive services, although a commenter who was supportive of the Utilization File overall recommended that the Departments nevertheless permit health plans to take reasonable steps to protect privacy for low-utilization items and services. A few commenters suggested that a more efficient approach to reduce the volume of unlikely provider-rate combinations from the In-network Rate File would be to specify that the In-network Rate File should only include negotiated rates where the provider submitted a claim during a specified lookback period, as discussed in section III.C.5. of this preamble.

The Departments acknowledge the burden associated with producing the Utilization File but have determined that it is largely a one-time cost, and the ongoing annual costs to update the file will not be a significant burden. The Departments recognize that the Utilization File will increase the overall volume of data disclosures but have determined that the increase will be offset by the reductions in the In-network Rate Files from removing unlikely provider-rate combinations, which the Utilization File is intended to verify. The Departments acknowledge that the Utilization File does not require new pricing disclosures and instead is intended to be a useful contextual addition to the In-network Rate File. The Departments disagree that the Utilization File will not be useful to consumers and regulators. Rather, the Departments have determined that the Utilization File is an essential component of the set of proposals, alongside the Excluded Provider Information provision and the Taxonomy File, that work in conjunction to remove duplicative and minimally useful information, while ensuring meaningful data disclosures. As explained in section III.C.5. of this preamble, if a file user identifies in the Utilization File providers that were reimbursed (or would be reimbursed but for cost-sharing liability) for items or services they submitted claims for during the plan or policy year, and these provider-rate combinations were included in the Taxonomy File but excluded in the In-network Rate File, that would indicate that the plan or issuer improperly excluded the provider-rate combination from the In-network Rate File. Removing unlikely provider-rate combinations from the In-network Rate File was a primary recommendation of interested parties, and the Utilization File enables verification of the accuracy of those excluded provider-rate combinations. Without being able to conduct this cross-check, the public would not know whether plans and issuers have properly excluded unlikely provider-rate combinations from the In-network Rate Files, resulting in questions regarding the reliability and usefulness of the overall disclosures. Additionally, the Departments determined that the Utilization File is less operationally complex and less expensive than the alternatives discussed in section V.E.2. of this preamble.

The Departments recognize the potential privacy concerns that commenters raise but have determined that a binary indicator of utilization is a strong guardrail against the possibility of identifying individual patients. The Departments disagree that requiring plans and issuers to exclude negotiated rates for a provider who has not submitted a claim during a specified lookback period is sufficient to address unlikely provider-rate combinations. Doing so would result in the exclusion of claims submitted by newer providers and providers who perform rare services, which could result in a loss of useful plan-level data. The Departments emphasize that unlikely provider-rate combinations are being excluded from the In-network Rate File because these combinations were likely not thoroughly negotiated and therefore may not provide accurate pricing information. This would not be true of claims that were not submitted during a specified lookback period for other reasons. Additionally, file users would have no means of verifying the accuracy of these exclusions.

The Departments also proposed at 26 CFR 54.9815-2715A3(b)(2)(ii), 29 CFR 2590.715-2715A3(b)(2)(ii), and 45 CFR 147.212(b)(2)(ii), to require the Utilization File to include data for the 12-month period that ends 6 months prior to the publication date of each Utilization File, to allow for enough time for plans and issuers to complete the claims processing lifecycle including pre-claim submission, pre-claim payment, and payment determination and collection.\82\

\82\ FinThrive, Understanding the Claims Lifecycle: A Step-by- Step Guide (November 26, 2024), https://finthrive.com/blog/understanding-the-claims-lifecycle-a-step-by-step-guide.

A commenter endorsed a lookback period that includes items and services rendered within a recent 12-month period. A commenter opposed the proposed lookback period, stating that the value of the data captured with the longer lookback would not outweigh the potential distortions in data quality, and does not support this longer lookback. Another commenter suggested a longer delay of 9 or 12 months would be acceptable. A commenter recommended the lookback period be aligned with the one required for reporting Percentile Allowed Amounts in the Hospital Price Transparency machine-readable files (12-15 months). Another commenter suggested that the lookback period should cover approximately 18 months to 6 months prior to the data release (although this comment also encouraged the inclusion of volume data).

The Departments agree that a lookback period approximating 12 months should capture a sufficient amount of information while balancing burden concerns. The Departments have determined that, to promote consistency across plan and issuer Utilization Files, a lookback period aligned with the most recent plan or policy year, which is typically 12 months, that ends at least 6 months prior to the date the Utilization File is made available is an effective balance between allowing for enough time for plans and issuers to complete the claims processing lifecycle and avoiding potential distortion concerns from a longer lookback period that would include data that crosses plan years. Thus, after consideration of comments, the Departments are finalizing the requirement for the Utilization File to include data for the most recent plan year (in the individual market, policy year) that ends at least 6 months prior to the date the Utilization File is made available as specified in paragraph (b)(4)(iii).

The Departments received one comment recommending that aggregate data comparing claims submitted to claims paid--broken out by service type--would help determine whether contracted reimbursement levels translate into actual payment and access. The Departments appreciate the comment but note that it is out of scope. c. Taxonomy File

In the proposed rules, the Departments proposed at new 26 CFR 54.9815-2715A3(b)(2)(iii), 29 CFR 2590.715-2715A3(b)(2)(iii), and 45 CFR 147.212(b)(2)(iii) to require plans and issuers to make available, in a machine-readable format, a Taxonomy File that includes the plan's or issuer's internal provider taxonomy, which maps items and services (represented by a billing code) to provider specialties (represented by specialty code which are derived from the NUCC) to determine if the plan or issuer should deny reimbursement for an item or service because it was not furnished by a provider in an appropriate specialty. The Departments designed this proposal to help file users understand how plans and issuers would determine which provider-rate combinations to exclude from the In-network Rate Files under proposed paragraph (b)(1)(i)(F). The Departments solicited comment on the Taxonomy File proposal, including whether there are other provider taxonomy code sets commonly used by plans and issuers other than the ones established by the NUCC or if there are other commonly used processes for plans and issuers to determine which providers should be reimbursed for which types of items and services, based on specialty, and which providers should not. The Departments also sought comment on how frequently plans and issuers update their internal taxonomy used during the claims adjudication process.

After consideration of comments, the Departments are finalizing the Taxonomy File with three modifications: first, adding that plans and issuers must base the Taxonomy File on their internal provider taxonomy or other internal rules used during the claims adjudication process to determine if the plan or issuer should deny reimbursement for an item or service based on the provider's specialty; second, specifying that the information provided in the Taxonomy File, regardless of whether it is based on an internal taxonomy or other internal rules, must be expressed as pairings of items and services (represented by billing codes) with provider specialties (represented by specialty codes which are derived from the Health Care Provider Taxonomy code set established by the National Uniform Claim Committee (NUCC)); and third, a technical modification renumbering the paragraph as 26 CFR 54.9815- 2715A3(b)(2)(ii), 29 CFR 2590.715-2715A3(b)(2)(ii), and 45 CFR 147.212(b)(2)(ii) (from paragraph (b)(2)(iii), as proposed) to account for the Departments not finalizing the Change-log File requirements in proposed paragraph (b)(2)(i).

Many commenters supported the proposed Taxonomy File and the required disclosure of each plan's and issuer's provider-to-service mappings, citing the expected reductions in file size and improvements to the quality of the data in the In-network Rate File. These commenters also acknowledged that the Taxonomy File would be critical to understanding how plans and issuers conduct their exclusions of unlikely provider-rate combinations in the In-network Rate File. A commenter noted that the Taxonomy File would help ensure that providers are comparing the most appropriate contracted rates when multiple provider or taxonomy types may all render services using the same Current Procedural Terminology (CPT) or Healthcare Common Procedure Coding System (HCPCS) code sets.

The Departments agree that requiring the disclosure of the taxonomy mapping that drives the provider-rate exclusions in the In-network Rate File is essential for transparency. Without it, file users would be unable to evaluate whether the provider-rate exclusions from a

plan's or issuer's In-network Rate Files align with the internal provider taxonomy the plan or issuer uses during its claims adjudication process or whether data is being improperly omitted.

A few commenters, while supportive of the Taxonomy File overall, were concerned that the variety of plan and issuer taxonomies and associated claims adjudication systems could lead to further extraneous and limited-use data issues. A commenter emphasized that there are valid reasons for plans and issuers to maintain permissive billing code-provider-specialty mappings, such as multi-specialty group practices contracting for the wide range of services potentially delivered and accommodating for errors in providers' codes. Another commenter pointed out that not all claims adjudication platforms utilize sophisticated, granular taxonomy logic, and many systems are not nuanced enough to filter rates effectively. A commenter added that the Departments should be careful to avoid implying that taxonomy codes alone “authorize” or “prohibit” provision of specific services and clearly describe the semantics as administrative adjudication mapping logic (not clinical scope-of-practice rules).

The Departments acknowledge that the possibility of permissive mappings for multi-specialty group practices may lead to keeping a slightly higher volume of unlikely provider-rate combinations in the In-network Rate File than would be included if the Departments established a standardized taxonomy. However, as discussed in this section of this preamble, the Departments accept the possibility of larger file size as a result both because such permissive taxonomies will increase the insight into how plans and issuers are conducting their provider-rate exclusions and because other changes finalized in these rules will more substantially reduce file size.

Additionally, the Departments intend for the Taxonomy Files to reveal the various rules plans and issuers use to determine whether to deny reimbursement for an item or service based on the provider's specialty, both to effectively verify plans and issuers are excluding unlikely provider-rate combinations correctly and to offer researchers and other file users potentially valuable insights into the degree of standardization in these rules used by plans and issuers.\83\ The Departments discuss the effects of permissive mapping systems and unique internal taxonomies more in section III.C.5. of this preamble. In addition, as discussed in section III.C.5. of this preamble, the Departments are modifying paragraph (b)(2)(ii) to account for the fact that some plans and issuers use internal rules other than a provider taxonomy that matches billing codes with specialty codes to determine whether to deny reimbursement for an item or service because it was not furnished by a provider in an appropriate specialty. Therefore, the Departments are finalizing paragraph (b)(2)(ii) to require that the Taxonomy File must include the plan's or issuer's internal provider taxonomy, or other internal rules, used to determine if the plan or issuer should deny reimbursement for an item or service based on the provider's specialty. The Departments are also finalizing paragraph (b)(2)(ii) to be more clear that, regardless of how the internal provider taxonomy or other rules used to determine whether to deny reimbursement given a provider's specialty are organized, that information must be expressed in the Taxonomy File as pairings of items and services (represented by billing codes) with provider specialties (represented by specialty codes which are derived from the Health Care Provider Taxonomy code set established by the National Uniform Claim Committee (NUCC)).

\83\ 90 FR 60432, 60459 (December 23, 2025).

A commenter requested that the Departments require plans and issuers to include in the Taxonomy File additional data disclosures to enhance the public's understanding of negotiated rate information, including name, address, and specialties belonging to each individual in-network NPI.

The Transparency in Coverage requirements are designed to make public information that was previously unavailable. NPI-identifying information is publicly available in the National Plan and Provider Enumeration System (NPPES) data. As the Departments explained in the preamble to the 2020 final rules, the “lack of availability of provider names in the machine-readable files is not a significant concern. The Departments anticipate that third-party internet-based developers and other secondary entities will be able to link the NPIs in the machine-readable files to publicly available provider information.” \84\ Additionally, requiring this information could significantly increase file size and would not be expected to provide commensurate benefit.

\84\ 85 FR 72158, 72225 (November 12, 2020).

A few commenters supported the proposed requirement for plans and issuers to map their internal taxonomies to the NUCC code set as the standard baseline from which plans and issuers derive their particular taxonomic specialty mappings. A commenter requested that the Departments require specialty identifiers disclosed in required public files to correspond to valid NUCC taxonomy codes to ensure that any specialty identification used for public disclosure is consistently expressed using the NUCC taxonomy code set. Another commenter encouraged the Departments to work with NUCC to ensure that the most up-to-date published code set is used. Alternatively, a few commenters expressed concern with the NUCC code set as a viable baseline, noting that it is not an accurate reflection of provider scope of practice, many codes are out of date, and some taxonomy fields are often incorrect or incomplete in the NPPES NPI Registry. A commenter urged the Departments to consider mechanisms that are more encompassing of the scope of different provider specialties and that account for the evolving nature of health care service delivery.

Many commenters emphasized the necessity of a standardized set of provider specialty codes as a baseline for plans' and issuers' unique taxonomic systems. These commenters reported the widespread use of custom codes, which would make it hard for file users to compare exclusions and taxonomies across plans and issuers. In contrast, a few commenters questioned the validity and usefulness of the NUCC code set and related NPPES taxonomies as a baseline, pointing out that they may be out-of-date or inaccurate. A commenter requested clarification on whether payers must align to the NPI registry.

The Departments have determined that the NUCC code set is an effective baseline and industry standard from which many plans and issuers establish their internal taxonomies for the purpose of determining if the plan or issuer should deny reimbursement for an item or service based on the specialty of the provider that furnished it. As discussed in section III.C.5. of this preamble, a plan or issuer will be required to apply its internal provider taxonomy, or other internal rules, used in its adjudication process to determine whether to deny a claim based on provider specialty by mapping its item or service and provider specialty pairings to the appropriate billing and NUCC codes. The Departments clarify the expectation that any unique specialties a plan or issuer includes in their Taxonomy File must map to existing NUCC taxonomy codes. As discussed in section III.C.5. of this

preamble, if a plan or issuer uses internal rules other than a provider taxonomy to determine whether to deny a claim for an item or service because it was not furnished by a provider in an appropriate specialty, the plan or issuer would first need to derive specialty to billing code combinations from those internal rules before mapping them to the appropriate billing and NUCC codes. This traceability will help file users determine how a plan or issuer is conducting its unlikely provider-rate exclusions. The Departments recognize that the NUCC code set and NPPES data set, or particular aspects of them, may not be up to date or may contain missing information. However, the Departments' objective with the Taxonomy File is to make transparent, and to allow the public to verify, the system a plan or issuer uses in practice to determine whether to deny a claim based on provider specialty and in its In-network Rate File to remove unlikely provider-rate combinations. The Departments are requiring plans and issuers to utilize the NUCC code set because it is the most common and widely utilized set of definitions of provider specialty areas and therefore will likely be the easiest for plans and issuers to map their taxonomies or other internal rules to. The Departments acknowledge that plans and issuers may use portions of the NUCC code set that are outdated and may consider requiring plans and issuers to identify the version of the NUCC code set the plan or issuer is utilizing in future iterations of the files. As each plan's and issuer's taxonomy or other internal rules are revealed, the Departments and the public will be able to analyze and gain a deeper understanding of how standard (or unique) taxonomies are composed, and the Departments may consider that dynamic for future iterations of the Taxonomy File requirement. For now, the goal remains to gain transparency into the landscape of taxonomies as it currently exists.

The Departments also emphasize that the Utilization File can act as a further check on the Taxonomy File. If the Utilization File reveals that a plan or issuer reimburses a claim for which its provider-rate mapping does not appear in the Taxonomy File, that would indicate to file users that the Taxonomy File may not be complete, accurate, or up to date. The Departments clarify that a plan or issuer does not need to align their taxonomic mapping to the NPI registry.

A few commenters requested that the Departments require plans and issuers to disclose the methodology used to develop their internal provider taxonomy to provide greater clarity alongside the taxonomies themselves. Some commenters recommended allowing plans and issuers who do not use a provider taxonomy-to-service-code map during their claims adjudication process to post a provider taxonomy-to-service-code map based on a large normative claims data set.

The Departments appreciate the commenters' suggestion but emphasize that the goal of the Taxonomy File is to reveal plans' and issuers' billing code-provider specialty mappings or other internal rules to ensure that provider-rate combinations are excluded properly, not the underlying rationale behind plans' and issuers' claims adjudication processes. For plans and issuers that have not developed a formal billing-code-to-provider-specialty taxonomy, but instead rely on other internal rules to determine whether to deny claims for items or services given the provider's specialty, the methodology for creating a Taxonomy File is discussed in more detail in section III.C.5. of this preamble. The Departments will provide additional technical direction to plans and issuers on how to build their Taxonomy Files in collaboration with industry on GitHub.

A few commenters suggested that the Departments could increase confidence in the information in the Taxonomy File and, consequentially, the provider-rate exclusions in the In-network Rate File, by establishing audit procedures to verify that the billing code- provider specialty mappings are accurate representations of the plan's or issuer's claims adjudication process and allowing for the public to challenge inappropriate exclusions.

The Departments appreciate commenters' interest in ensuring that information included in the Taxonomy Files is accurate and reliable but have determined that existing compliance and enforcement procedures, as discussed in section II.D. of this preamble, are sufficient to ensure the integrity of the machine-readable files. An important layer of these procedures includes allowing the public to raise specific concerns of possible non-compliance with the Departments. The Departments encourage the public to continue to report compliance concerns on the CMS Price Transparency website.\85\

\85\ Centers for Medicare & Medicaid Services, Health Plan Price Transparency: Contact Us, https://www.cms.gov/priorities/healthplan-price-transparency/overview/contact-us (last updated February 11, 2026).

Several commenters proposed, as an alternative, that the Departments publish a single, standardized taxonomic list that all plans and issuers would use in support of the provider-rate exclusion process. One example shared by a commenter was a comprehensive but conservative national whitelist of taxonomy-to-service relationships. These commenters asserted that a standardized list would: (1) increase usability and comparability of the In-network Rate Files; and (2) create opportunities for third parties to aggregate and analyze information at scale. Another commenter noted that, because there could potentially be a high number of clinically appropriate edge cases within each plan's or issuer's internal taxonomy, the Taxonomy File would have to include each of those unique issuer-specific logics. Instead, that commenter proposed a set of narrowly defined guardrails and a limited exceptions pathway for uncommon but legitimate scenarios. Some commenters proposed as an alternative that the Departments adopt a standardized exclusion methodology, which would also affect the Excluded Provider Information proposal discussed in section III.C.5. of this preamble.

While the Departments acknowledge, and emphasize elsewhere in these final rules, the benefits and importance of standardized reporting criteria, the Departments have determined that requiring a standard taxonomy is premature at this stage and may limit the Departments' ability to achieve their higher-order goals. While the Departments acknowledge that standardization may eventually be beneficial, the Departments have determined that standardizing taxonomic disclosures effectively is not possible until the Departments better understand the differences in provider-specialty mapping (or other internal rules used during claims adjudication to determine whether to deny a claim given the provider's specialty) among plans and issuers. Based on the many comments indicating how plans and issuers build their taxonomies in non-standard ways, the Departments are concerned that requiring a one- size-fits-all approach could result in unacceptable data gaps, fail to sufficiently reduce file size, and reduce the ability of the public to fully understand the data in the machine-readable files. The Departments additionally noted in the proposed rules the opportunity for “researchers and other file users [to gain] potentially valuable insights into the degree of standardization in mapping used by plans and issuers, and how this varies

across different market types.” \86\ This variety and nuance of each plan's and issuer's internal taxonomies or other internal rules is a feature that the Departments want to reveal both for the purposes of greater transparency and for the ability to refine requirements in future iterations of the Taxonomy File requirement.

\86\ 90 FR 60432, 60459 (December 23, 2025).

A commenter suggested that plans and issuers make access to the Taxonomy File available through the use of an API. The Departments recognize the benefits of API access to large volumes of information, but as discussed in section III.C.9. of this preamble, the Departments are not requiring the use of APIs at this time due to substantial new development costs on plans and issuers and the effectiveness of delivering the required information through the modified and redesignated file format requirements at 26 CFR 54.9815- 2715A3(b)(3)(i), 29 CFR 2590.715-2715A3(b)(3)(i), and 45 CFR 147.212(b)(3)(i) which will increase file format standardization and improve accessibility.

Many commenters disagreed with the proposal for a Taxonomy File, predominantly due to the burden of developing and producing the file and the fact that differences across plans and issuers would make data less usable and comparable. A few commenters added that the information the Taxonomy File would reveal goes beyond the scope of the transparency requirements by requiring information unrelated to pricing and contracted rates. A commenter was confident that the proposed requirements on plans and issuers at 26 CFR 54.9815-2715A3(b)(1)(i)(F), 29 CFR 2590.715-2715A3(b)(1)(i)(F), and 45 CFR 147.212(b)(1)(i)(F) to exclude provider-rate combinations, along with existing enforcement mechanisms, is sufficient to achieve the Departments' goals without the need for publishing a Taxonomy File. Another commenter suggested that the Taxonomy File was not the best approach to address the issue of unlikely provider-rate combinations but was not opposed to the Taxonomy File as an option. Another commenter believed that the problem of unlikely provider-rate combinations could be addressed by owners of provider networks voluntarily removing such combinations from their machine-readable files.

The Departments disagree that the information disclosed in the Taxonomy File goes beyond the scope of the transparency requirements and maintain that this information falls directly within the categories of information that plans and issuers can be compelled to disclose under section 1311(e)(3)(A) of the Affordable Care Act and section 2715A of the PHS Act.\87\ The Taxonomy File provides essential contextual information for file users, the public, and ultimately consumers to better and more fully understand the disclosures in (and the exclusions from) the In-network Rate File. The extensive feedback from comments referenced throughout this preamble confirms this. Without the added context of the Taxonomy File, there would be a lack of transparency around the new provider-rate exclusions. The public would have no way of knowing if the providers listed in the file are actually unlikely to be reimbursed for furnishing the items or services they are paired with, which may leave the public with limited confidence in the actionability and reliability of the In-network Rate File. In addition to promoting the transparency of the required in- network rate disclosures, the Taxonomy File also serves as a way for the Departments and the public to hold plans and issuers accountable for the accuracy of the provider-rate exclusions in their In-network Files.

\87\ Section 1311(e)(3)(A)(i) through (viii) of the Affordable Care Act outlines specific information and data that must be submitted to the public and certain other entities on an accurate and timely basis. In addition, section 1311(e)(3)(A)(ix) of the Affordable Care Act requires health plans to submit “[o]ther information as determined appropriate by the Secretary.” As the Departments explained in the 2020 final rules, “the catchall provision is reasonably and best read as Congress' recognition that the Secretary of HHS (and, therefore, the Departments, by virtue of their joint authority under section 2715A of the PHS Act) would need broad flexibility to require the disclosure of information as appropriate to deliver the transparency necessary for consumers to understand their coverage options and for regulators to hold plans and issuers accountable. 85 FR 72158, 72167-68 (November 12, 2020).

The Departments recognize that requiring a new machine-readable file imposes new burdens on plans and issuers through a one-time cost to update the programmatic code to exclude unlikely provider-rate combinations and to create and publish a new Taxonomy File. The Departments discuss these estimates in section IV.B. of this preamble and note that any additional ongoing costs associated with maintaining Taxonomy Files are expected to be minimal because the files are expected to rely primarily on existing internal taxonomy mappings and code sets, or other internal rules used to determine if the plan or issuer should deny reimbursement for an item or service based on the provider's specialty, that plans and issuers already maintain and periodically update as part of their normal claims adjudication and operational processes. Additionally, as the Departments explained in the 2020 final rules, “building the first machine-readable file will facilitate the automation of the process to build future files. In other words, the ability to produce subsequent files should be streamlined after completing initial development.” \88\ The Departments have determined that the transparency benefits to the public from being able to validate plans' and issuers' provider-rate exclusions and gain confidence in the reliability of the information in their In-network Rate Files through the documentation in the Taxonomy File are critical and outweigh the burden.

\88\ 85 FR 72158, 72243 (November 12, 2020).

The Departments also recognize, as discussed previously in this section, that there will be a great deal of variety across Taxonomy Files, and, while this may make comparison between plans and issuers challenging, the primary goal of this file is for file users to understand how plans and issuers determine which provider-rate combinations to include in the In-network Rate Files and which to exclude. Additionally, the data in the file will be organized in a standardized way (for example, billing code-NUCC code pairings), which the Departments expect will help minimize variability across files.

A commenter was concerned that file users would interpret the inclusion of a particular code in the Taxonomy File to guarantee that it is appropriate to bill for and should be paid in all instances. Another commenter was concerned that bad actors would take advantage of the publication of billing code-provider specialty mappings to commit fraud.

The Taxonomy File is meant to illustrate what could happen in the billing process, while the Utilization File, which the Departments are finalizing in paragraphs 26 CFR 54.9815-2715A3(b)(2)(i), 29 CFR 2590.715-2715A3(b)(2)(i), and 45 CFR 147.212(b)(2)(i), is meant to illustrate what happened with regard to claim reimbursement over the designated lookback period, as described in section III.C.11. of this preamble. The Departments acknowledge that taxonomy codes are “not used to define services rendered, but instead are used to define area of specialty.” \89\ A particular code appearing in the Taxonomy File is meant to represent

that it would likely be accepted as part of the billing code-provider specialty mapping or other internal rules used to determine whether to deny reimbursement based on provider specialty. That is, it indicates that a plan or issuer would likely not deny payment for an item or service on the basis of the provider's specialty, and it does not indicate that a provider's specialty alone is sufficient to guarantee payment. File users can consult the Utilization File to determine whether any claims have been reimbursed for that billing code-provider specialty mapping. It is not immediately clear how bad actors would take advantage of the Taxonomy File to commit fraud.

\89\ National Uniform Claim Committee, Health Care Provider Taxonomy, https://www.nucc.org/index.php/code-sets-mainmenu-41/provider-taxonomy-mainmenu-40 (last visited May 12, 2026).

The Departments received one comment recommending that the Departments require plans and issuers to post: (1) all claims for each provider (as currently occurs for Medicaid FFS, Medicaid MCO plans, Medicare FFS, and Medicare Advantage plans); and (2) calculations of weighted average reimbursement data by provider type. The Departments note that this comment is out of scope. d. Text File

In the proposed rules, the Departments proposed to add paragraphs 26 CFR 54.9815-2715A3(b)(2)(iv), 29 CFR 2590.715-2715A3(b)(2)(iv), and 45 CFR 147.212(b)(2)(iv), requiring plans and issuers to post a plain text file in .txt format (Text File) in the root folder (the top-level directory on an electronic file system) of a plan's or issuer's website that would include: (1) the source page URL for the internet website that hosts machine-readable files required under paragraphs (b)(1) and (2); (2) a direct link to the URL for the machine-readable files required under paragraphs (b)(1) and (2); and (3) point-of-contact information including an up-to-date name, title, and email address for an individual who can address inquiries and issues related to the machine-readable files required under paragraphs (b)(1) and (2).\90\ Under the proposal, this contact information must be prominently displayed on the same website where the machine-readable files are made available and be kept updated per the requirements in paragraph (b)(4)(vi) of this section. The Departments intended this information to allow users to more easily locate the plan's or issuer's machine- readable files, increasing both automated and non-automated access to the machine-readable files. Additionally, and as discussed in section III.C.10. of the proposed rules, the Departments proposed to add paragraph (b)(4)(vi) to require plans and issuers to post a Text File beginning on the first day of the calendar-year quarter following the applicability date under paragraph (c)(1) and subsequently update the Text File as soon as practicable but not later than 7 calendar days following a change in any of the information required under paragraph (b)(2)(iv) of the proposed rule.

\90\ The proposed rules proposed requirements in relation to the prescription drug machine-readable files at proposed paragraphs (b)(2)(iv) (relating to the proposed requirement to include a plain text file in a .txt format in the root folder of a plan's or issuer's website) and (b)(3) (relating to the method and format for disclosing information to the public) of 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3, and 45 CFR 147.212.

The Departments requested comment on all aspects of this proposal, and in particular on whether the Departments should issue guidance regarding whether any standards are required to ensure that the identified point of contact for plans and issuers is responsive to inquiries submitted by file users (such as a timeline to respond to inquiries or designated hours of availability for phone contact, and, if so, the recommended timeline and designated hours) or whether additional forms of contact (such as a physical address) are necessary.

After consideration of comments, the Departments are finalizing this proposal with modifications to allow plans and issuers to provide a monitored email address for either an individual or a group dedicated to receiving and responding to inquiries and issues related to the machine-readable files required under paragraphs (b)(1) and (2) of this section, in lieu of requiring the point-of-contact information to include a specific named individual with their title. As explained in section III.C.8.a. of this preamble, the Departments are redesignating this proposal from paragraph (b)(2)(iv) to paragraph (b)(2)(iii) because the Change-log File proposal at paragraph (b)(2)(i) is not being finalized. The Departments are finalizing the other parts of paragraph (b)(2)(iv), redesignated as paragraph (b)(2)(iii), as proposed.

Many commenters supported the proposal to require a Text File in the root directory of a plan or issuer's website. Commenters noted that this approach would improve file discoverability by enabling automated file retrieval, reducing the time users spend manually navigating inconsistent website structures, and aligning with existing Hospital Price Transparency requirements. A commenter also stated that locating the standardized Text File in the root folder would reduce search costs for third-party developers and the public, ultimately making the disclosures actionable and more usable in practice.

The Departments agree that a standardized Text File in the root folder that includes the proposed data elements would significantly improve the discoverability and usability of machine-readable files, ultimately making the files more transparent to the public. In response to ongoing interested party feedback that file placement varies across plans and issuers and can be difficult to locate on a plan's or issuer's website, the Departments have determined that requiring a Text File at a consistent, predictable location addresses this barrier by providing a direct link to the machine-readable files and eliminates the need for users to navigate varied website structures. Additionally, as the Departments noted in the preamble to the proposed rules, this requirement is consistent with the approach adopted under the 2023 Hospital Price Transparency final rule, which requires hospitals to post a Text File in the root folder of the hospital's public website that includes a direct link to the hospital's machine-readable file.\91\

\91\ 90 FR 60432, 60460 (December 23, 2025) (citing 88 FR 81540 (November 22, 2023)).

Several commenters urged the Departments to require plans and issuers to submit their Transparency in Coverage file locations, or the information contained in the root-level Text File, to CMS or DOL for inclusion in a centralized, publicly accessible DOL or CMS-hosted repository. These commenters cited multiple benefits, including improved file discoverability, reduced redundant web crawling, streamlined compliance monitoring, enhanced regulatory oversight, and greater permanence and authority of file location data. A few commenters noted that a centralized repository would reduce the burden on self-funded plans that lack the infrastructure to implement root- directory hosting independently. A commenter stated that a centralized repository would enhance the accountability of entities producing the machine-readable files and support the Departments in conducting compliance assessments more efficiently. Another commenter noted that this approach would reduce burdens on employers and other data users at a negligible cost to the Federal government and with no additional burden on group health plans, service providers, and issuers. A few commenters noted that centralized indexing of transparency file locations has proven feasible at the State level

and could be adopted at the Federal level.

The Departments have determined that establishing and maintaining the infrastructure necessary to support a centralized repository would require additional resources and costs that the Departments are unable to presently absorb. The Departments are, however, improving discoverability by requiring plans and issuers to disclose in the Text File, the source page URL for the website hosting the machine-readable files required under paragraphs (b)(1) and (2) of this section and, a direct link to that URL. As discussed in the preamble to the proposed rules, this provides users with a predictable location of where the machine-readable files are hosted, rather than requiring them to search through inconsistent website constructs. With respect to self-funded group health plans, the Departments note that they may contract with their service providers to satisfy this requirement per paragraph (b)(5)(ii). The required inclusion of the source page URL and a direct link to that URL in the Text File will allow users to more easily locate the plans or issuer's machine-readable files, increasing both automated and non-automated access to these files. The Departments are also finalizing the footer requirement, which further improves findability of the website hosting the machine-readable files, as discussed later in this section. The Departments will continue to evaluate centralized approaches as resources allow. The Departments acknowledge the possibility that a centralized repository would facilitate compliance and enforcement. While the requirements finalized in this rule do not establish a centralized repository, the standardized Text File and website footer significantly reduce the discoverability barriers noted by commenters by providing a consistent means of locating machine-readable files on each plan's or issuer's website. The requirements afford regulators, third-party developers, and the public the ability to identify missing or inaccurate files and report potential non-compliance. As a result, the Departments have determined it is both reasonable and efficient to continue to use existing processes to ensure compliance with the Code, ERISA, and PHS Act requirements that apply to group health plans and health insurance issuers, as discussed in section II.C. of this preamble.

Several commenters, while supportive of requiring plans and issuers to disclose clear point-of-contact information for error reporting and issue resolution related to machine-readable files, recommended the Departments modify this provision to allow plans and issuers the flexibility to include a designated email address or mailbox for a team that is responsible for responding to inquiries or issues, rather than the name and title of an individual employee. Commenters noted that most plans already manage technical and compliance inquiries through monitored group inboxes or teams to efficiently triage requests, regardless of staffing changes or turnover. A few commenters cited security concerns with listing an individual's name in a publicly accessible file. Another commenter noted that allowing plans and issuers to designate a specific group or office to respond to inquiries allows for cross-training and other staffing approaches to maximize resources rather than relying on a single individual. A commenter acknowledged this provision's alignment with the hospital machine- readable file requirements, noting that the more hospital and payer machine-readable files standards converge, the more the industry would be held to alignment and accountability as the norm, rather than the exception. A commenter characterized the individual point-of-contact requirement as an arbitrary, one-size-fits-all approach that fails to account for smaller or more efficient insurers.

Another commenter agreed that an email address would be the most effective way to contact a payer office or team responsible for the machine-readable file inquiries, rather than a telephone number or physical address. A commenter, while agreeing with the value of including contact information for someone knowledgeable about the files, recommended that CMS establish required response timeframes (for example, 10 business days) and minimum qualifications for designated points of contact to ensure they have actual technical knowledge.

The Departments agree with commenters that the goal of the point- of-contact information in the Text File--enabling the public to report technical issues or receive assistance with accessing or using the files--can be accomplished by a named individual or a dedicated group or team. As commenters noted, requiring the name, title, and email address of a specific individual may mean responses are delayed if the individual assumes a new role or is temporarily unavailable. The Departments expect that permitting a group or team of individuals to triage requests may help promote continuity and responsiveness, particularly where plans or issuers already have teams in place to handle technical and compliance inquiries. Therefore, rather than requiring the point-of-contact information to include a specific named individual with their title and email address, the Departments are modifying the point-of-contact requirement that was proposed in paragraph (b)(2)(iv)(C), and redesignated as paragraph (b)(2)(iii)(C) in these final rules, to allow plans and issuers the flexibility to designate a monitored email address for an individual or group dedicated to receiving and responding to inquiries and issues related to the machine-readable files. This change promotes better alignment with the point-of-contact requirement under the Hospital Price Transparency framework, which permits the use of a dedicated email address for this purpose.\92\ This modification is also responsive to comments from a significant number of commenters who raised privacy, security and operational concerns with the named-individual requirement.

\92\ See U.S. Department of Health & Human Services, Centers for Medicare & Medicaid Services (CMS), Hospital Price Transparency TXT File Frequently Asked Questions (FAQs), (August 29, 2024), available at https://www.cms.gov/files/document/hospital-price-transparency-txt-file-frequently-asked-questions-faqs.pdf.

The change from an individual “who can address inquiries and issues” related to the machine-readable files to instead require a monitored email address for an individual or group “dedicated to receiving and responding to inquiries and issues” related to the machine-readable files reflects commenter feedback about the importance of an actively responsive contact, and clarifies that the Departments expect the point of contact to actually respond to the inquiries received, rather than just be able to respond. The Departments agree with commenters that an email address is the most efficient way to contact a plan or issuer and receive prompt responses to technical inquiries related to the machine-readable files, and therefore, are not finalizing additional parameters, such as response timeframes. Establishing a standard response timeframe, such as a 10-business-day requirement, may not account for the scope, scale, and complexity of potential inquiries that may vary significantly. In addition, this may strain existing technical resources and lead to incomplete responses, which would run counter to the goal of maintaining accurate and reliable information. The Departments understand that plans and issuers are best positioned to determine the response standards appropriate to their existing workflows, and many plans

may leverage existing monitored inboxes that already have response timeframes and other business processes in place. Under these final rules, and consistent with the flexibility described in paragraph (b)(3)(iv), nothing would prevent a group health plan or health insurance issuer that contracts with a service provider to provide the machine-readable files on their behalf from contracting with the service provider to include the service provider's contact information in the Text File and for the service provider to answer technical questions related to the files on behalf of the plan sponsor. However, if the service provider fails to include their point-of-contact information or to answer technical questions in compliance with redesignated paragraph (b)(2)(iii)(C), the plan or issuer would be considered to violate the transparency disclosure requirements of that paragraph. While the Departments have determined that it is unnecessary to establish specific minimum qualification requirements for the designated points of contact, the Departments stress that whoever receives and responds to inquiries and issues related to the machine- readable files must be familiar both with the requirements of 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3 and 45 CFR 147.212, as applicable, as well as how to access and use information in the machine-readable files.

A few commenters noted that the root-directory requirement is impractical for many self-funded employer plans, as most do not maintain public-facing websites and rely on service providers to host machine-readable files on their behalf. These commenters appreciated the Departments' acknowledgment that existing paragraph (b)(5)(ii) and proposed paragraph (b)(3)(iv) would allow such plans to contract with their service provider to meet machine-readable file requirements under this section but requested additional clarity on how the root-directory requirement applies to service provider-hosted files. Both commenters emphasized that clear accountability is necessary to avoid non- compliance. A commenter stated that when a service provider hosts files on behalf of a self-funded plan, regulatory accountability for data accuracy and completeness should remain with the plan sponsor, and that delegation of hosting should not equate to delegation of responsibility.

The Departments acknowledge that many self-funded group health plans do not maintain their own public websites. To address this, the Departments note that under the special rules at paragraph (b)(5)(ii), a group health plan or health insurance issuer may satisfy the requirements under paragraph (b) by entering into a written agreement under which another party, such as a service provider or health care claims clearinghouse, provides the information required by paragraph (b) in compliance with this section. Accordingly, a plan without its own public website can, through a written agreement, have the service provider post the Text File in the root folder on the service provider's public website on behalf of the plan. The Departments clarify that delegation of hosting responsibilities to a service provider through a written agreement does not alter the compliance obligations of the plan. The plan remains responsible for ensuring that the requirements of this section are met, regardless of which entity hosts the files.

A commenter recommended that the Table of Contents File become a mandatory component of the Transparency in Coverage framework, citing practical advantages related to file discovery and retrieval. The commenter noted that it is operationally efficient for the root file to point to a single Table of Contents File rather than to potentially hundreds or thousands of individual In-network Rate Files. The commenter stated that the Table of Contents File can serve as an index that organizes and references all underlying machine-readable files in a predictable and scalable manner, reducing clutter at the root level and providing a standardized entry point for both human users and automated systems.

The Departments emphasize that the root file does not need to point to every individual In-network Rate File and Allowed Amount File, only the location where those individual files can be found. As the Departments noted in section III.C.1. of this preamble, current technical implementation guidance specifies that a Table of Contents File is needed if more than one plan or policy offered by a plan or issuer shares the same in-network rates. The Departments plan to continue to refine this guidance in future iterations, as discussed in more detail in section III.C.1. of this preamble.

A commenter stated that much of the information provided in the proposed Text File is already publicly available through State requirements and member benefit accumulators, characterizing the proposal as largely duplicative. The commenter also stated that the internet-based self-service tool, which reflects a consumer's actual benefits, is the more useful option for consumers. The commenter encouraged the Departments to work with interested parties to determine the Text File format if the requirement is finalized.

The Text File serves as a findability tool designed to enable data users, including third-party developers, researchers, employers, and automated systems to locate the machine-readable files at a standardized, predictable location. By requiring plans and issuers to publish file locations in this consistent format, these final rules help ensure that the underlying data in the files are readily accessible to all members of the intended audience. The Text File does not serve the same function as consumer-facing cost tools or member benefit accumulators, which provide individualized cost estimates based on a consumer's specific plan benefits. Rather, the Text File will address the issues that file users experience in locating machine- readable files across plan's and issuer's websites. As the Departments explained in the 2020 final rules, these file users include researchers, legislators, and regulators, as well as application developers who could make the information usable and easily understood by all purchasers of health care items and services, such as individual consumers, employers, and government health care programs.\93\ The Departments note that interested parties will have the opportunity to provide further feedback on the format of the Text File alongside other required machine-readable files requirements through GitHub, as part of the development of the future technical implementation guidance. For the reasons described above, the Departments do not agree that the Text File requirement is duplicative and are finalizing the requirement as proposed.

\93\ 85 FR 72158, 72169 (November 12, 2020).

A commenter, while generally supportive of the Departments' efforts to improve findability, observed that Transparency in Coverage files are already more easily locatable than hospital files and tend to be generated and hosted by a small set of vendors or upstream carriers. The commenter noted that, given this dynamic, a standardized or shorter pathway to files may not provide as much benefit as was experienced from the Hospital Price Transparency framework.

While the Departments recognize that Transparency in Coverage machine-readable files are generated and hosted by a more concentrated set of entities than the Hospital Price Transparency files, the Departments continue to receive feedback from file users and other interested parties, including many of the commenters on the proposed

rules, that significant findability challenges persist across Transparency in Coverage data. Multiple commenters reported that plans and issuers continue to host files in inconsistent locations, use non- standard naming conventions, and fail to provide easily discoverable links. The Departments are confident that requiring a standardized Text File in a consistent root-level location will materially improve access for data users and that consistency across plans and issuers is important to the effectiveness of the transparency framework. 9. File Format

In the 2019 proposed rules, the Departments asked whether the required machine-readable files should be published in a single, specified, non-proprietary format, specifically JSON, noting that JSON is generally easily downloadable and may facilitate use of the data by developers and other file users.\94\ In the 2020 final rules, however, the Departments declined to codify a single file type, explaining that rapid technological change supported preserving flexibility to identify technical specifications through implementation guidance rather than regulation. Accordingly, the 2020 final rules required that the files be made publicly available, free of charge, and without conditions, in a non-proprietary, open format, consistent with guidance issued by the Departments.

\94\ 84 FR 65464, 65481 (November 27, 2019).

In the proposed rules, the Departments sought comment on whether the collective experience of file producers and file users since 2019 warranted greater standardization, including whether the machine- readable files should be published in a single non-proprietary, open- standards format, and whether that format should be JSON or CSV. The Departments explained that earlier technical guidance had contemplated multiple formats, including JSON, XML, and CSV, but that file developers had largely since converged on JSON, with internal analysis indicating that more than 90 percent of plans and issuers were already using that format. The Departments also sought comment on whether the required information in paragraphs (b)(1) and (2) should be required to be disclosed through an electronic data transfer technology, such as a publicly accessible API, as well as what standards should apply. The Departments also sought comment on whether the use of a standards-based API would benefit consumers, developers of consumer-facing applications, and other entities seeking to access this data.

In the preamble to the proposed rules, the Departments emphasized a strong inclination toward specifying a single, non-proprietary open- standards format in technical implementation guidance that would “reduce flexibility for plans and issuers in selecting alternate file formats but would further standardize reporting of critical health care pricing information” and added that “specifying a single format presents an important part of fully realizing the goals of price transparency and Executive Orders 13877 and 14221.” \95\

\95\ 90 FR 60432, 60461 (December 23, 2025).

After considering the public comments received, the Departments have determined that restricting plans and issuers to a single publication format, to be specified in guidance issued by the Departments, is appropriate and beneficial to the ongoing production and use of the machine-readable files. The Departments have determined that this approach provides consistency by standardizing a single file format while preserving flexibility to adapt to future technological developments. Furthermore, the Departments intend to specify JSON as the required format for the In-network Rate File, Allowed Amount File, Utilization File, and Taxonomy File in guidance because, at this time, JSON best supports the current structure and exchange of Transparency in Coverage data and aligns with existing market implementation. The Text File, as described in section III.C.8.d. of this preamble, must be published in .txt format, which is also a single, non-proprietary, open standard. By contrast, the Departments have concluded based on comments received that it would be premature to adopt API requirements or standards in these final rules, and that further infrastructure development and community engagement is needed prior to the development of standards for any future API. Therefore, the Departments are redesignating 26 CFR 54.9815-2715A3(b)(2), 29 CFR 2590.715- 2715A3(b)(2), and 45 CFR 147.212(b)(2) as 26 CFR 54.9815-2715A3(b)(3), 29 CFR 2590.715-2715A3(b)(3), and 45 CFR 147.212(b)(3) and amending redesignated 26 CFR 54.9815-2715A3(b)(3)(i), 29 CFR 2590.715- 2715A3(b)(3)(i), and 45 CFR 147.212(b)(3)(i) to require that, unless otherwise specified in 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3, and 45 CFR 147.212, the machine-readable files described in paragraphs (b)(1) and (2), in addition to being made available in the form and manner specified by the Departments in guidance, must be made available in a single, non-proprietary, open-standard format, as specified in guidance.

A few commenters expressed general support for designating a particular file format for the machine-readable files without providing feedback on whether to do so in the Departments' proposed method of restricting plans and issuers to a single file format in regulatory text and then specifying the designated format in guidance. The Departments appreciate the commenters' support of the goal to make the disclosed data more uniform and usable and published in the file format that best serves the many audiences who use the machine-readable file data.

Many commenters discussed the pros and cons of the JSON file format, with most concluding that JSON would be the most logically required format, as it is the predominant format used by payers, aligns with the CMS schema validator, and provides a structure to represent relationships between plans, networks, providers, and rates. A few commenters noted it would be burdensome to require payers to use a different file format other than JSON, given its prevalence. A commenter recommended not allowing any formats other than JSON, while another commenter suggested JSON be required, with optionality for other file formats. A commenter wanted the Departments to align coding conventions and structural elements across plan and hospital transparency requirements. A commenter recommended the Departments designate Newline-Delimited JSON as the required format. A commenter concluded that JSON is an inefficient format for users with limited computing resources. Another commenter added that the files, as currently produced, are confusing and sometimes inaccessible.

The Departments have concluded that JSON offers significant advantages as a publication format for the machine-readable files. As discussed in the proposed rules, JSON is already the predominant format used in the market, with over 90 percent of plans and issuers having chosen JSON for their published machine-readable files (including an extremely small number using Newline-Delimited JSON).\96\

Because the overwhelming majority of plans and issuers already publish in JSON, and because downstream users have built significant ingestion and validation tooling around the existing JSON ecosystem, requiring a different format now would likely create significant transition costs for issuers, service providers, and file users. Commenters reinforced the Departments' determination that JSON, as a hierarchical format, is particularly well-suited to representing the complex and nested relationships reflected in Transparency in Coverage data, including relationships among plans, networks, providers, billing codes, and negotiated rates, without requiring extensive repetition of the same data values. The Departments agree with commenters that JSON's broad native support across programming languages and modern data tooling, and its usefulness across all phases of the Extraction, Transformation, Load (ETL) process, make it a highly effective publication format for these disclosures, and a practical format for downstream transformation by third-party developers, researchers, and regulators. On the technical side, the Departments recognize JSON as both self-describing and human-readable, which can help users understand the data structure by performing visual checks of JSON-formatted files. The Departments acknowledge that JSON may be a challenge for users with limited computing resources and may appear inaccessible as a result but note that there are free tools available to assist consumers in accessing and interacting with the files, and data in JSON format can be readily transformed into more accessible formats. For all these reasons, the Departments plan to designate JSON in guidance as the single, non- proprietary, open-source file format standard for the machine-readable files.

\96\ 90 FR 60432, 60461 (December 23, 2025). Newline-Delimited JSON (NDJSON) is a variation of JSON in which each line contains a single JSON object, while JSON has a single root object containing the entirety of the dataset. NDJSON files would not comply with the current schema version in technical implementation guidance.

In discussing an alternative, a few commenters recommended that, if the Departments standardize on a single format, the Departments should adopt a relational CSV approach or tabular type (for example, denormalized, multiple linked tables), because commenters believed a relational CSV design could preserve hierarchical relationships while reducing file size and improving analytic usability. A few other commenters did not support the Departments standardizing machine- readable files to CSV or other “flat” tabular formats, because the commenters believed that CSV would require duplicative, denormalized structures to represent the Transparency in Coverage nested schema, thereby increasing file size and processing burden, and making the data less workable at scale. A commenter suggested the Departments undertake a full review of CSV before choosing it as a file format.

The Departments considered requiring or designating CSV, given that some researchers and file users may prefer to work with rectangular or table-based data structures. As discussed in the proposed rules, the Departments received feedback that some file users, especially researchers, migrate machine-readable file data from JSON to CSV to conduct analyses, and that CSV may be more familiar and visually accessible for some users.\97\ However, the Departments disagree that CSV or other flat tabular formats are the most appropriate format for the machine-readable files. Given that the Transparency in Coverage data are large and structurally complex, and CSV does not natively represent nested relationships, the Departments remain concerned, as commenters indicated, that using CSV or any row-based flat file structure for publication of data of this scale would require extensive denormalization or other conventions to preserve those relationships. The Departments agree with the expectation that this would create substantial inefficiencies and repetition of shared values across very large numbers of rows, such that redundant data values would be repeated up to millions of times per file. The Departments agree with commenters who stated that requiring a transition from the current predominant JSON approach to a single alternative format (for example, CSV) would create significant technical complexity, implementation risk, and costs.

\97\ 90 FR 60432, 60461 (December 23, 2025).

For these reasons, the Departments have determined that adopting CSV as the required file format would not lead to file size reductions or increased file usability. The Departments agree that data structure is an important consideration in determining how usable machine- readable file data will be for researchers, developers, and regulators. The Departments considered the commenters' view that linked-table or relational structures may simplify some downstream analytics and may make it easier for certain users to load data into common database or analytics tools. However, the Departments are not finalizing a requirement that the machine-readable files be published in a relational or rectangular structure. As discussed in the responses elsewhere in this section, the Departments have determined that the required publication format must be evaluated in light of the full range of uses and the underlying characteristics of the Transparency in Coverage data. As such, the Departments note this file format requirement using JSON helps the Transparency in Coverage machine- readable files more closely align with the Hospital Price Transparency requirements. Both rules use JSON as an allowable file format. Even though the Hospital Price Transparency requirements allow for JSON and CSV, this restriction to just a single file format brings the Transparency in Coverage rules more in alignment with the Hospital Price Transparency rule by narrowing the scope of permissible formats compared to when previously allowing any open-source format.

A few commenters discussed the pros and cons of the Parquet file format. A commenter believed it would make the most sense as a required format, another suggested the Departments review its merits and limitations before requiring it, and another recommended allowing Parquet as an optional or permitted format. A few commenters suggested that rectangular, linked tables, or relational data sets, would better serve the purpose of simplifying the machine-readable files. These commenters explained that Parquet files can be compressed, are compatible with analytics tools and programming languages, can represent nested data structures, and support efficient data reading and writing.

The Departments recognize that the Parquet file format has important advantages for certain downstream analytic uses and may be especially useful for some researchers and other users working with large datasets in mature analytics platforms. Parquet is a columnar, binary format that can reduce storage requirements, support efficient querying of large data sets, and improve reading and writing performance in some analytic environments. Parquet is generally better suited to later stages of the ETL process--particularly the loading and querying of already-transformed data in analytic environments--than to the initial public disclosure of raw Transparency in Coverage data for broad reuse across many use cases. Designating Parquet as the only acceptable file format would assume a common end-stage analytic use that is not shared by all file users. The Departments also remain concerned that requiring Parquet now would impose substantial transition costs, as discussed elsewhere in this section. In addition, JSON has other advantages over Parquet as a standard for the

machine-readable files, in that JSON is self-describing and human- readable, which helps users understand the data structure and perform visual checks, whereas Parquet is a binary format that is not human- readable, and working with it generally requires specialized software. The Departments therefore conclude that, while Parquet may be valuable for some downstream users after transformation, it is not the most appropriate required publication format for the machine-readable files at this time.

The Departments therefore agree that requiring a different single format, particularly CSV or Parquet, would be disruptive, and could undermine rather than improve standardization in the near term. Additionally, for all the reasons discussed in this section, the Departments have determined that a different single file format would not achieve the usability and standardization goals that JSON has achieved.

A commenter suggested that for smaller and less resourced plans, submitting rate contracts in lieu of a standardized file format would be preferred. Another recommended the Departments consider allowing plans and issuers to publish complete, unredacted provider contracts as an alternative to producing machine-readable JSON files.

The Departments acknowledge that some plans and issuers may face greater operational or technical difficulties than others in producing and maintaining machine-readable files, particularly where technical resources are limited. The benefit of the standardized machine-readable file format finalized here is that it improves the comparability, consistency, and practical usability of those disclosures across the market. Publishing underlying contracts instead of standardized machine-readable files would not provide the same uniform, machine- readable, and broadly reusable format for aggregation, validation, analysis, and consumer tool development that these final rules are intended to support.

A few commenters recommended that the Departments not specify a required file format and instead continue to allow format flexibility to plans and issuers. One of the commenters asserted that it is not necessary for the Departments to specify the file type, as there are widely available conversion tools that convert data represented in a standardized relational, rectangular structure to a different format of choice. A few commenters suggested that the Departments relay file format preferences in sub-regulatory formats instead of in rulemaking.

The Departments recognize the benefits of maintaining flexibility for plans and issuers to publish the machine-readable files in a variety of formats, and for users to engage with the files more easily in their preferred format. However, the Departments have determined that identifying a specific file format will improve data usability for the public. The Departments also disagree that the availability of conversion tools eliminates the need to specify a single publication format. While conversion tools may help some users transform the published data into their preferred analysis format, they do not eliminate the need for a consistent, standard publication format for purposes of validation, comparability, and broad market-wide usability. The Departments agree that maintaining the specific format requirement in guidance allows the Departments to respond more quickly to technological changes, implementation experience, and future improvements in data exchange methods, while establishing in regulation the clear expectation that the machine-readable files must be published in a single non-proprietary, open-source file format.

A few commenters recommended that plan-specific claims data be provided in standardized, X12 837-compatible electronic format.

The Departments have determined that this would introduce unnecessary complexity given that the X12 837-compatible electronic format is designed to convey patient-specific information at a transactional level, versus general negotiated rate information between payers and providers. As such, to switch to an X12 837-compatible electronic format would require extensive modifications or implementation guidance to achieve what the In-network Rate Files are designed to provide. Further, while the Allowed Amount Files are designed to provide some out-of-network claims information (that is, allowed amounts and billed charges) that are the output of claims processing, a similar amount of guidance to redact personally- identifiable information and other extraneous transactional information would ultimately transform such a format into something unrecognizable as a standard X12 837, eliminating any benefit to be gained by using such a standardized format, including re-using existing claims- processing software. Ultimately, the machine-readable files are reports of information that can be found in multiple payer systems and not just claims adjudication systems, and the Departments have determined that by reporting a standardized machine-readable file format that only includes the information necessary for the purpose of meeting the Transparency in Coverage disclosure requirements as specified under 26 CFR 54.9815-2715A3(b)(1), 29 CFR 2590.715-2715A3(b)(1), and 45 CFR 147.212(b)(1), payers have the flexibility to determine the best and most efficient way to produce the required information.

Many commenters supported the idea of requiring or enabling disclosure of rate information through a publicly accessible, standards-based API, because APIs would provide more usable, scalable, and programmatic access than downloading and processing very large machine-readable files. Several commenters specified that APIs should use the Fast Healthcare Interoperability Resources (FHIR) standard and specific FHIR-based implementation guides to support consistent implementation and cross-entity interoperability. A commenter suggested the Departments provide a central, standardized API for users to access machine-readable file data.

On the other hand, a few commenters expressed opposition to a requirement for API-based disclosure of Transparency in Coverage machine-readable file information at this time, because an API requirement would add cost, complexity, and security and operational risks, without clear incremental benefit over file posting. A few commenters stated that requiring API-based disclosure would introduce a fundamentally different operational model that would require plans and issuers to build and maintain new infrastructure and would introduce significant engineering complexity. A few commenters recommended the Departments delay considering a publicly accessible API requirement and instead revisit APIs in future notice-and-comment rulemaking, because commenters believed plans and issuers were already facing significant operational work to implement the proposed file restructuring and newly required files.

The Departments agree that requiring plans and issuers to make pricing data available through a standards-based API could ultimately spur competition and reduce the burden on application developers to innovate around providing more user-friendly and effective applications for consumers. However, the Departments also agree with commenters that the current ecosystem around the machine-readable files is insufficiently mature to specify what the core functions for future APIs

ought to be, and consequently, what the required architecture for APIs ought to look like. Moreover, the Departments have determined that any version of building out API requirements and standards would impose substantial new development costs on the issuer community, above and beyond the costs of the current machine-readable file requirements as specified under 26 CFR 54.9815-2715A3(b), 29 CFR 2590.715-2715A3(b), and 45 CFR 147.212(b), especially as plans and issuers are currently implementing other interoperability requirements. The Departments also have concerns regarding the longer-term burden required for the ongoing operation and maintenance of APIs. For example, large volumes of repeated data requests could strain a future API infrastructure drawing on machine-readable files and thereby create performance challenges. With regard to using FHIR as the appropriate standard for a Transparency in Coverage API, the Departments have determined that additional research and industry community input is required before a decision on a specific standard can be promulgated through rulemaking or technical guidance. Moreover, the Departments would want to engage a designated standards maintenance organization in helping to guide the Departments in any related API-standard setting before undertaking any future rulemaking or technical specifications regarding APIs. Therefore, the Departments are not finalizing a requirement that plans and issuers provide the rate information required under paragraphs (b)(1) and (2) through a publicly accessible API.

The Departments received a few out-of-scope comments. A commenter suggested that commercial contracts should remain free to negotiate prices within these classifications but should not be permitted to substitute proprietary grouping systems that defeat the comparability this rule is designed to create. Another commenter supported APIs as part of a broader request for interoperability, including for digital insurance cards and “connectathons.” The Departments do not respond to these comments because they are out of scope. 10. Required Method and Format for Disclosing Information to the Public

The Departments made several proposals related to the method and format of disclosing information to the public. As discussed in section III.C.8. of the proposed rules, the Departments proposed to redesignate paragraphs (b)(2) and (3) of 26 CFR 54.9815-2715A3, 29 CFR 2590.715- 2715A3, and 45 CFR 147.212 as paragraphs (b)(3) and (4), respectively. The Departments proposed to add paragraph (iii) to redesignated paragraph (b)(3) to require that the source page URL for the internet website that hosts the machine-readable files required by paragraph (b)(1) and new paragraph (b)(2) must be included as a link in the footer on the home page of the group health plan's or health insurance issuer's website, as well as any page of the website that features a footer, that is labeled “Price Transparency” or “Transparency in Coverage” and links directly to the publicly available web page that hosts the link to the machine-readable files.\98\ The Departments are finalizing new paragraph (b)(3)(iii) as proposed.

\98\ The proposed rules proposed requirements related to prescription drug machine-readable files at proposed paragraph (b)(3) (relating to the method and format for disclosing information to the public) of 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3, and 45 CFR 147.212.

Many commenters supported the proposal to improve machine-readable file discoverability through a standardized website footer link. Commenters agreed that a standardized footer link would make it easier for users to locate the Transparency in Coverage machine-readable files, which support the Departments' broader goal of improving access and consistency across plans and issuers. A commenter characterized the footer link as a low-effort, consumer-facing improvement. A few commenters supported the alignment with the Hospital Price Transparency framework, noting that a standardized footer link would improve efficiency in locating health plan price files. A commenter noted that the footer link, in combination with the Text File, would prevent plans and issuers from being transparent in-name-only by burying information on their websites and instead require outward-facing transparency that meaningfully benefits consumers.

The Departments agree that a standardized footer link labeled, “Price Transparency” or “Transparency in Coverage” will provide a consistent, predictable navigation path for consumers and other users seeking access to plans and issuers' machine-readable files. Further, the Departments have determined that this requirement will promote consistency across pricing disclosure initiatives since this approach aligns with the Hospital Price Transparency framework at 45 CFR 180.50(d)(6)(ii), where standardizing the placement and labeling of these links were also intended to improve file accessibility. The Departments also agree with commenters that the footer link, together with the Text File requirement, will ensure that compliance with the machine-readable file requirements provides meaningful public access to the data.

A commenter recommended the Departments require the footer hyperlink to be labeled “Transparency in Coverage” rather than permitting “Price Transparency” as an alternative. The commenter noted that some plans currently use “Price Transparency” to describe member-facing shopping resources, including personalized cost estimator tools, and that consumers encountering a “Price Transparency” link may expect those tools rather than the file user-oriented machine- readable files. The commenter stated that a single, consistent label would reduce ambiguity across the market and improve navigation for both consumers and technical users.

The Departments are finalizing two label options, “Price Transparency” and “Transparency in Coverage,” to provide plans and issuers the flexibility to organize their price transparency information in a manner that is intuitive for their users. As an example, a plan may choose to consolidate its machine-readable files, consumer cost tools, and other pricing disclosures under a single “Price Transparency” heading or may choose to maintain a distinct “Transparency in Coverage” heading to differentiate the machine- readable files from other consumer-facing resources. In selecting one of the two permissible options, plans and issuers are encouraged to organize the linked content in a way that facilitates clear navigation for all of their respective users.

The Departments also proposed to add paragraph (iv) at redesignated 26 CFR 54.9815-2715A3(b)(3), 29 CFR 2590.715-2715A3(b)(3), and 45 CFR 147.212(b)(3), in line with guidance issued on April 19, 2022 in FAQs Part 55,\99\ but extended to apply to issuers, such that any plan or issuer could satisfy the disclosure requirements of paragraph (b)(3)(iii) by entering into a written agreement under which another party posts the machine-readable files on its public website on behalf of the plan or issuer. The Departments determined that, for a plan or issuer that does not have a public website, it would be overly burdensome to require such

plan or issuer to create and maintain a website to satisfy this requirement. The Departments proposed extending this flexibility to issuers, which were not covered under the guidance in FAQs Part 55, so that this compliance option would be available to all entities subject to the requirements of paragraph (b)(3)(iii). Additionally, the Departments proposed that if the files are hosted on a service provider's website, and the plan or issuer does maintain a public website and chooses not to also post the files separately on its own public website, the plan or issuer would be required to provide a link on its own public website to the location where the files are made publicly available. This requirement would apply to a public website maintained by the plan or issuer and would not apply to a public website maintained by an employer or plan sponsor. This proposed new paragraph would also move part of current 26 CFR 54.9815- 2715A3(b)(4)(iii), 29 CFR 2590.715-2715A3(b)(4)(iii), and 45 CFR 147.212(b)(4)(iii) addressing plans or issuers who do not have a website to new paragraph (b)(3)(iv) for clarity and alignment with other proposed changes. The Departments received no comments on this proposal and are finalizing it as proposed.

\99\ See U.S. Department of Labor, U.S. Department of Health & Human Services & U.S. Department of the Treasury, FAQs about Affordable Care Act and Consolidated Appropriations Act, 2021 Implementation Part 55 (August 19, 2022), https://www.cms.gov/files/document/faqs-part-55.pdf and https://www.dol.gov/agencies/ebsa/about-ebsa/our-activities/resource-center/faqs/aca-part-55.

The Departments also proposed to redesignate paragraph (b)(2) as paragraph (b)(3), and proposed to make three changes: First, the Departments proposed to divide the existing language in paragraph (b)(2) into two paragraphs at redesignated paragraphs (b)(3)(i) and (ii); second, the Departments proposed to indicate at redesignated paragraph (b)(3)(ii) that the machine-readable files in paragraphs (b)(1) and (2) (instead of paragraph (b) generally, as currently written) must be available in a form and manner as specified in guidance issued by the Departments; third, the Departments proposed to amend redesignated paragraph (b)(3)(ii) to ensure that the machine- readable files remain publicly accessible to automated scripts and web crawlers as well as human users. The Departments are finalizing the first two changes as proposed and are finalizing the third with modifications to use consistent singular phrasing--“any person, automated script, or web crawler”--for grammatical clarity.

The Departments did not receive any comments on the first proposal to divide and redesignate paragraph (b)(2) and therefore are finalizing as proposed. The Departments also did not receive any comments on the second proposal to specify in redesignated paragraph (b)(3)(i) that the machine-readable files in paragraphs (b)(1) and (2) (instead of paragraph (b) generally, as currently written) must be available in a form and manner as specified in guidance issued by the Departments and are finalizing as proposed with the modification to do so unless otherwise specified in 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3, and 45 CFR 147.212. With regard to the third proposal, the Departments also did not receive any comments but are clarifying, to match the language in paragraphs (b)(3)(i) and (iii), that the machine-readable files in redesignated paragraph (b)(3)(ii) refer to the ones in paragraphs (b)(1) and (2).

The Departments proposed to amend redesignated paragraph (b)(3)(ii) to specify that the machine-readable files must remain publicly available and accessible to any person, automated scripts, or web crawlers free of charge and without conditions such as establishment of a user account, password, submission of personally identifiable information or other credentials, or blocking server configurations or firewalls to access the file. The Departments explained that requiring the machine-readable files to be available to both human and automated users would more directly align with the purpose of the files being in a machine-readable format. The Departments also provided examples of conditions that they would consider a barrier to file access including requiring a user to enter an EIN, TIN, or a plan name to access a specific file; requiring a user to encounter a “CAPTCHA,” \100\ or a 403 error; \101\ or limits on the number of downloads allowed by a user or at a time. The Departments stated that once a human user or automated web crawler arrives at the website of the plan or issuer, they should be able to identify the specific location of the files. The Departments determined that making this information more easily accessible to automated searches and data aggregation would help third parties to develop tools that further assist the public in understanding this information and capturing it in a meaningful way for making informed health care decisions.

\100\ See IBM, What is CAPTCHA?, available at https://www.ibm.com/think/topics/captcha (last visited May 4, 2026) (“CAPTCHA stands for `completely automated public Turing test to tell computers and humans apart.' It refers to various authentication methods that validate users as humans, not bots, by presenting a challenge that is simple for humans but difficult for machines.”).

\101\ See Mozilla, 403 Forbidden, available at https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403 (last updated July 4, 2025) (“The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it.”).

Several commenters supported the requirement to ensure machine- readable file availability and accessibility to both manual and automated users, citing ongoing barriers to automated access such as non-crawlable URLs and download throttling, and the importance of explicit access to both human users and automated scripts. A few commenters cited the use of CAPTCHAs as an ongoing obstacle to automated access. A commenter noted that some plans and issuers impede automated access to their machine-readable files by blocking requests from IP address ranges from major cloud providers. Another commenter requested that the Departments clarify that “publicly available” means accessible via straightforward HTTP requests.

A commenter opposed the requirement to ensure that machine-readable files are available and accessible to both manual and automated users due to security concerns. The commenter requested that the Departments revise the proposed “without conditions” requirement to permit plans and issuers to implement reasonable technical safeguards. The commenter added that such a change risks eliminating widely used and accepted basic security and resiliency controls that are necessary for operating any public-facing infrastructure at scale.

The Departments agree that preserving automated and manual access to machine-readable files is key to ensuring availability of the machine-readable files as public information. The Departments are aware that access to the machine-readable files comes predominantly from automated systems and reaffirm that barriers limit accessibility. The Departments have observed instances of plans and issuers preventing users from accessing their full set of machine-readable files by requiring users to enter an EIN or HIOS identifier to access a single file at a time, when the intention has always been for a user to have direct access to all of a plan's or issuer's machine-readable files without obstruction. The Departments recognize that plans and issuers have an interest in utilizing security and resiliency strategies to maintain server uptime and the availability of the files for public download. However, the Departments understand that features that impede access to the machine-readable files, such as CAPTCHAs and rate limiting, result in a barrier to automated ingestion of machine- readable files and prohibit public users from effectively accessing the data and engaging with the files. Therefore, the Departments are not revising the

“without conditions” requirement. However, the Departments note that, as part of their enforcement, they will take into consideration whether a plan was trying to protect itself from distributed denial of service attacks in evaluating whether a plan or issuer was obstructing manual and automated access to the machine-readable files.\102\

\102\ See Cybersecurity and Infrastructure Agency, Understanding Denial-of-Service Attacks, https://www.cisa.gov/news-events/news/understanding-denial-service-attacks (last updated Feb. 1, 2021).