Transparency in Coverage

The Departments proposed to add new 26 CFR 54.9815- 2715A3(b)(1)(i)(E), 29 CFR 2590.715-2715A3(b)(1)(i)(E), and 45 CFR 147.212(b)(1)(i)(E) to require group health plans and health insurance issuers to include in each In-network Rate File, current numerical enrollment totals, as of the date the file is posted, for each coverage option offered by a plan or issuer represented in the In-network Rate File. Such numerical enrollment totals would include the number of participants, beneficiaries, and enrollees (including all dependents) in the coverage option offered by a plan or issuer. In the proposed rules, the Departments explained that in response to feedback received since the publication of the 2020 final rules, additional data elements, such as plan enrollment numbers, that would allow users to weigh different plans and coverage options to understand their relative influence on the overall landscape of pricing in health insurance, would be in line with the goals stated in the 2020 final rules.\51\ The Departments solicited comment on the feasibility of including the enrollment total as of the date the file is posted, whether an enrollment total on a different specified date would be more feasible for file producers and more useful to data users, and on the proposal in general.

\51\ 85 FR 72158, 72161 (November 12, 2020); see also Gary Claxton, Lynne Cotter, & Shameek Rakshit, Challenges with Effective Price Transparency Analyses, Peterson-KFF Health System Tracker (February 25, 2025), https://www.healthsystemtracker.org/brief/challenges-with-effective-price-transparency-analyses/.

After consideration of comments, the Departments are not finalizing the proposal to include numerical enrollment totals in the In-network Rate File.

Several commenters supported requiring group health plans and health insurance issuers to include the number of participants, beneficiaries, and enrollees (including dependents) for each coverage option represented in the In-network Rate File. These commenters stated that such enrollment data would improve the analytical usefulness of the files by providing more consistent contextual information about the reach of benefit arrangements, supporting analysis of market power and pricing trends, enabling comparison across plans and coverage options, and helping purchasers identify appropriate benchmark groups.

A few commenters recommended that the Departments consider including county-level enrollment counts to help researchers, regulators, and businesses to better understand relative market power and act upon enrollment data. A commenter urged the Departments to review methodologies on county-level enrollment as used in Medicare Advantage plans to see how they could be applied to the In-network Rate Files. Commenters also recommended clarifying enrollment attribution by limiting the total to individuals directly enrolled with the reporting plan or issuer to help avoid confusion arising from collaborative agreements across separate payer entities who share provider networks, and that multiple plans and issuers can provide a single member with network access.

Several commenters recommended reporting enrollment totals in the Table of Contents File or other plan level metadata rather than within each In-network Rate File, stating that a centralized approach would provide a more consistent reporting location, reduce duplication and reconciliation burden, and simplify implementation for plans and service providers. A commenter further recommended quarterly updates to the Table of Contents File and adding a standardized enrollment total field to the reporting plan object.

Several commenters did not support requiring plans and issuers to include the number of participants, beneficiaries, and enrollees (including dependents) for each plan or coverage option represented in the In-network Rate File. The commenters noted that enrollment and rate data reside in separate, incompatible systems, making

compliance operationally impracticable and adding complexity in reconciling the data since member-level systems are not available for machine-readable file generation. Another commenter expressed concern that requiring exact enrollment totals may create operational burden and reporting instability. The commenter noted that enrollment figures are inherently fluid and difficult to measure precisely at a single point in time and therefore recommended allowing rounded estimates to balance transparency goals with administrative feasibility, data consistency, and comparability across plans and issuers.

Finally, a commenter recommended that the Departments convene a structured workgroup of interested parties on enrollment reporting to support implementation and help troubleshoot operational issues prior to issuing final guidance for reporting enrollment totals.

The Departments agree with commenters' assessment of the operational difficulties in reporting enrollment numbers at the plan level and are also concerned that the differences in data systems, reporting methodologies, and reconciliation processes could increase the likelihood of inconsistent or inaccurate reporting across plans and issuers, thereby reducing the reliability and comparability of the data for users. After further consideration, the Departments are concerned that the potential value for certain uses of the enrollment counts are outweighed by the significant operational burden associated with implementing this requirement and updating the enrollment numbers quarterly, and potential unintended consequences to plans, issuers, and other businesses that could result from the disclosure of enrollment trends.

A few commenters supported requiring plans and issuers to include in each In-network Rate File current numerical enrollment totals “as of” the file posting date for each coverage option offered by a plan or issuer represented in the file. The commenters believed the “as of” file posting date is the clearest and most administratively feasible reference point for both file producers and data users. A few commenters recommended allowing a set date for reporting enrollment totals and recommended the date be the first day of the month preceding the filing quarter. The commenters believed this would reduce operational burden while still providing useful context for users. Another commenter urged the Departments to require annual enrollment reporting if it is infeasible or overly burdensome for plans and issuers to include enrollment totals as of the file posting date. A commenter recommended that the Departments set the enrollment total “as of” report date to the posting date of the previous In-network Rate File because they believed retrospective reporting would balance minimal uncertainty with offering users a more accurate representation.

Conversely, a few commenters did not support requiring plans and issuers to include enrollment totals as of any specific date for group health plans. The commenters noted that the enrollment total comprises multiple numbers that are built on separate data sources and requires time to compile, making near real-time reporting difficult.

A few commenters also expressed that enrollment numbers may be outdated by days or weeks which could mislead users, that enrollment totals are not necessary for an individual member to make provider cost comparisons, and that the information provides limited practical value for consumers. A few other commenters mentioned data accuracy concerns, which they believed would also increase the potential for misinterpretation. A commenter did not believe enrollment totals would fulfill the Departments' goal to enable users to build analytically sound and accurate comparisons of plans and issuers' enrollment data, nor would it reduce file size. Another commenter noted that enrollment data is already available for individual and small groups under the Unified Rate Review Template public use files.

The Departments have considered alternative reporting approaches, including in response to comments explaining that enrollment information is maintained in separate systems from other machine- readable file data and would need to be appended to the In-network Rate File. After consideration of those alternatives, the Departments agree with commenters who expressed concern that point-in-time enrollment reporting could quickly become outdated or misleading due to frequent enrollment fluctuations and retroactive eligibility adjustments. The Departments also agree that requiring the reporting of enrollment totals could increase operational complexity and create challenges related to data accuracy, consistency, and comparability across reporting entities. In addition, the Departments agree with commenters' concerns regarding the limited practical utility of enrollment information for consumers, while acknowledging that consumers are not typically the primary users of the In-network Rate Files. The Departments further recognize that publicly available sources may already provide certain enrollment-related information for portions of the health insurance market. For example, under the Prescription Drug Data Collection (RxDC) requirement, plans and issuers are required to report the number of participants, beneficiaries, and enrollees, as applicable, covered on the last day of the reference year for each plan or coverage.\52\ The Departments acknowledge this requires only annual reporting of the previous year's enrollment totals, whereas the Transparency in Coverage proposed requirement would require quarterly reporting of enrollment numbers which would increase the operational complexity and data validity challenges as previously mentioned.

\52\ See 29 CFR 2590.725-4(a)(3) and 45 CFR 149.740(a)(3); see also 26 CFR 54.9825-6T(a)(3) (expired).

A few commenters recommended clarification regarding where enrollment totals should be reported in the machine-readable files to ensure consistency across plans and issuers and how the different machine-readable file production scenarios would handle the enrollment totals. A commenter urged the Departments to clarify which enrollment totals apply when an employer plan generates In-network Rate Files at a plan-level compared to when a vendor produces a network-level In- network Rate File that includes the employer health plan's information. Specifically, the commenter questioned whether plan-level reporting should reflect overall plan enrollment or enrollment for a particular plan design option.

The Departments acknowledge these requests for clarification but because the proposal to require numerical enrollment totals in the In- network Rate File is not being finalized in these rules, such clarification is not necessary.

A few commenters expressed concerns regarding how reporting enrollment totals could compromise sensitive business information and the ability for plans and issuers to negotiate fair rates. A commenter noted that providers and third parties already are using data from published machine-readable files in rate negotiations and expressed concern that adding enrollment data would increase the likelihood of that practice, allowing providers to further identify areas for leverage in rate negotiations. The commenter stated that increased costs related to such practices would be passed on to consumers, ultimately undermining the cost-containment goal of price transparency. A commenter

noted that without proper context, users of machine-readable files may incorrectly use enrollment figures to draw conclusions about provider networks or plan popularity, which could undermine, rather than enhance, meaningful transparency. A commenter expressed that the granularity of coverage-level enrollee reporting could raise privacy or competitive concerns for small employers. the commenter recommended a defined enrollment threshold to protect small populations without creating gaps in data for larger plans where privacy risk is negligible. A commenter recommended reporting enrollment at both the plan and network levels. Another commenter noted that network enrollment data information would better support employers with health benefit negotiations, which typically are done at the network level.

The Departments carefully considered commenters' concerns that reporting enrollment totals could have unintended consequences that expose business vulnerabilities such as limiting ability to negotiate effectively--especially for smaller entities--and lead to higher prices for consumers. The Departments note that the intention of the In- network Rate File is to reveal pricing by provider network. While enrollment counts might give context to prices, they are not directly price related. The Departments acknowledge comments recommending reporting at the network level instead of the coverage level, which could minimize the risk that parties would take advantage of enrollment information to negotiate higher rates. However, the Departments are persuaded that the operational, implementation, data reliability, and business vulnerability concerns raised by commenters outweigh the potential benefits of finalizing this proposal, regardless of how enrollment counts are reported. In particular, the Departments are concerned that requiring enrollment reporting could be unduly burdensome due to the separation of enrollment and rate data systems and may result in inconsistent or potentially misleading reporting. Accordingly, the Departments are not finalizing the proposed requirement to include enrollment totals in the In-network Rate Files. 5. Excluded Provider Information

The Departments proposed to add new 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 the In-network Rate Files provision that would require group health plans and health insurance issuers to exclude from each In-network Rate File a provider and their negotiated rate (provider-rate combination) for an item or service, if the plan or issuer determines it is unlikely that such provider would be reimbursed for the item or service based on the scope of the provider's license or area of specialty. The Departments further proposed that plans and issuers must make such a determination using their internal provider taxonomy that is typically used during the claims adjudication process. The Departments determined that excluding provider-rate combinations that are not likely to result in a reimbursement is necessary to limit unnecessary information that inflates file size and limits the accessibility of the data in the In-network Rate File. The Departments also proposed to amend 26 CFR 54.9815-2715A3(b)(1)(i)(E)(2), 29 CFR 2590.715-2715A3(b)(1)(i)(E)(2), and 45 CFR 147.212(b)(1)(i)(E)(2) to direct plans and issuers not to include an in-network provider's National Provider Identifier (NPI), Tax Identification Number (TIN), and Place of Service Code if that in-network provider would be excluded as specified in paragraph (b)(1)(i)(F) of this section.

The proposed rules set forth at paragraph (b)(1)(i)(F) would require plans and issuers to use their internal provider taxonomy that is typically used during the claims adjudication process to determine which provider-rate combinations to exclude from the In-network Rate File. The internal provider taxonomy is part of the claims adjudication workflow, in which the plan or issuer assesses whether the billed item or service (represented by a billing code) aligns with the specialty of the rendering provider (represented by a provider taxonomy code). If the specialty does not meet the plan's or issuer's requirements for that item or service, the claim may be denied. For example, the Departments expect that a plan's or issuer's internal provider taxonomy would be unlikely to reimburse a claim submitted for a heart surgery submitted from a podiatrist because the billing code associated with a heart surgery would not match with a taxonomy code for a podiatrist.

The Departments understand that it is standard business practice for the internal provider taxonomy maintained by a plan or issuer to identify provider specialties using the standardized code set established by the National Uniform Claim Committee (NUCC) or their own model derived from it.\53\ The NUCC maintains standard provider taxonomy codes, which are used to define a provider's area of specialty.\54\ Provider taxonomy codes are ten characters in length structured into three distinct “levels” including provider grouping, classification, and area of specialization.\55\ The Departments understand that when a provider submits a claim for reimbursement to a plan or issuer, the provider must include their NUCC code and the billing code for the item or service along with certain other information. Plans and issuers then compare the NUCC provider taxonomy code and billing code included from the claim against their internal provider taxonomy mappings to determine if the claim can proceed through the next step of the payment adjudication process.

\53\ The NUCC establishes and maintains standard provider taxonomy codes, which are used to define a provider's area of specialty. Provider taxonomy codes are ten characters in length structured into three distinct “levels” including provider grouping, classification, and area of specialization. See National Uniform Claim Committee, Health Care Provider Taxonomy, available at https://www.nucc.org/index.php/code-sets-mainmenu-41/provider-taxonomy-mainmenu-40 (last visited May 4, 2026).

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

\55\ See id.

The Departments sought comment on all aspects of this proposal and were particularly interested in feedback from interested parties on whether there are plans or issuers that do not map provider specialties to billing codes within their claims adjudication process or use different code sets, and whether there could be a way to standardize the provider specialty-mapping-to-billing-code process. The Departments also sought comment on whether there are alternative approaches to excluding any provider that has a rate for an item or service that interested parties consider not to be a meaningful rate. The Departments also requested feedback from interested parties on the relative burdens and benefits of alternative approaches to both producers and file users. The Departments were also interested in any concerns that parties may have with a proposal to require plans and issuers to make such exclusions at all.

After consideration of public comments, the Departments are finalizing the requirements set forth 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) and 26 CFR 54.9815-2715A3(b)(1)(i)(E)(2), 29 CFR 2590.715-2715A3(b)(1)(i)(E)(2), and 45 CFR 147.212(b)(1)(i)(E)(2) as proposed, with one modification to require plans and issuers to exclude provider-rate combinations that are unlikely given the provider's specialty, according to either

the plan's or issuer's internal provider taxonomy or other internal rules used during the claims adjudication process.

Many commenters supported the proposals that would remove unlikely provider-rate combinations to decrease file size and increase data reliability and usability by removing “noise.” These commenters indicated that plans and issuers already utilize internal controls to map provider specialty or taxonomy to billing codes for the purposes of preventing payments when an item or service in a claim is inconsistent with the submitting provider's credentials. A few commenters asserted that removing unlikely provider-rate combinations should help employers make better purchasing decisions. A few other commenters added that finalizing this proposal would lead to reduced costs for compliance and system maintenance, and that a logical removal of implausible combinations represents a standardization that enhances usability without sacrificing transparency.

The Departments agree that requiring plans and issuers to exclude unlikely provider-rate combinations will lead to significant reductions in file size, increase the usability and reliability of the In-network Rate File data for providers, patients, and policymakers, and help employers make better purchasing decisions.

A few commenters, while supportive of the proposal, expressed concerns about implementation and emphasized the importance of clear instructions to plans and issuers on how to conduct the required provider-rate exclusions to avoid over-exclusion. A commenter noted that the exclusions would be administratively burdensome for owners of provider networks to implement and requested that the Departments provide technical assistance to these owners. Another commenter pointed out the potential for the provider-rate exclusion to appear in a non- standardized manner, given the potential differences in plans' and issuers' claims adjudication processes. A commenter requested that the Departments require plans and issuers to document the provider-rate combinations that are removed to increase the public's understanding of these exclusions. A few commenters encouraged the Departments to work with interested parties to identify the best way to design the parameters around provider-rate exclusions. Another commenter requested that the Departments go further and require plans and issuers to exclude negotiated rates from the In-network Rate File where plans or issuers have a reasonable belief that claims are no longer being submitted under the contract, including but not limited to instances where the plan or issuer has officially designated the contract as “dormant” or some other related term. However, a commenter recommended that the Departments permit plans and issuers to include a provider in the rate file for a specific service even if the provider has not historically performed the service within the network reflected in the file, which may be the case when the provider is in a multi- specialty group with combinations of TIN/EINs and NPIs. A commenter was concerned that implementor-defined taxonomy filters could result in data gaps, contributing to existing data usability issues.

The Departments intend to address many of these concerns through future technical implementation guidance to afford the Departments flexibility to determine appropriate technical reporting requirements and to make refinements in response to changes in technology and health care industry business practices. This future technical implementation guidance--in the form of contextual data attributes within schemas-- will provide clear instructions to plans and issuers, and the iterative development process through community feedback on GitHub will allow file producers and file users to help the Departments minimize over- exclusions and address non-standard arrangements. The Departments have determined that requiring plans and issuers to separately document the provider-rate combinations that are excluded from the In-network Rate File is unnecessary given that file users can verify the exclusions through examining the Taxonomy and Utilization Files, as discussed in section III.C.8. of this preamble. The Departments emphasize that the provider-rate exclusion must be based on the plan's or issuer's determination that it is unlikely a provider would be reimbursed for an item or service given that provider's specialty. This does not include an unlikely reimbursement based on other reasons, such as a dormancy period. A claims adjudication system relying on taxonomic specialties may still be able to reimburse for a claim submitted by a previously dormant provider if it meets the provider specialty-billing code mapping, regardless of a lack of recent claims.

Additionally, the Departments note for clarity, that these final rules require a plan or issuer to exclude unlikely provider-rate combinations using its internal logic used during the claims adjudication process to determine whether to deny reimbursement for an item or service given the provider's specialty--whether that internal logic is an internal provider taxonomy or other internal rules used for this purpose. The “internal provide taxonomy” referenced in this requirement is distinct from the “Taxonomy File” referenced in the new requirement discussed in section III.C.8.c. of this preamble. The Taxonomy File must contain a plan's or issuer's internal logic used during the claims adjudication process to determine whether to deny reimbursement for an item or service given the provider's specialty-- again, using an internal provider taxonomy or other internal rules used for this purpose--but reflected as pairings of billing codes and NUCC codes. The Departments therefore expect that plans and issuers may need to convert their internal rules into data suitable to be submitted in the Taxonomy File.

A commenter expressed concern that the proposed exclusion process would be used by issuers as a justification to improperly deny claims for the provision of services that may fall within a provider's lawful scope of practice but are not captured by the NUCC code set. The commenter requested that the Departments engage advanced practice provider organizations in reviewing and transparently validating the process used to determine which services are excluded for their respective specialties.

The Departments clarify that a plan's or issuer's determination of whether a provider is unlikely to be reimbursed for an item or service based on the provider's specialty must be made consistent with applicable law. This clarification recognizes that other provisions of Federal or State law may limit the circumstances in which a plan or issuer may distinguish among providers based on specialty, licensure, certification, or similar characteristics. For example, section 2706(a) of the PHS Act generally prohibits discrimination with respect to participation under a plan or coverage against a health care provider acting within the scope of the provider's license or certification under applicable State law. However, validating the process used to determine which services are excluded for their respective specialties is beyond the scope of these rules, which do not require plans and issuers to make any changes their claim adjudication processes or any rules they use to determine whether to deny reimbursement given the provider's specialty.

A commenter noted that the rule would prevent provider-rate combinations from other taxonomies being used as part of the process to

exclude unlikely provider-rate combinations but does not prevent posting a conversion factor or rate for procedures within the same specialty that are not performed and that this could lead to payers negotiating significantly lower rates with specialists for specific services they do not perform.

The Departments agree that a provider's taxonomy defines what they may be reimbursed for, not what they actually furnish. The Utilization File addresses this gap by identifying providers who submitted claims and received reimbursement (or would have been reimbursed but for cost- sharing liability) for items and services during the reporting period. This allows users to distinguish negotiated rates for items and services actually furnished from those that are not, without requiring plans to make service-level determinations about individual practices. The Departments will monitor whether the Utilization File serves this purpose effectively. The Departments also acknowledge that details about negotiated arrangements, such as conversion factors and rates, can vary among providers within the same specialty and could lead to ambiguous negotiated rates. To address this, the Departments continue to include an open text field in the schema to enable plans and issuers to clarify or account for these unique scenarios and will continue to evaluate the possibility of standardizing such arrangement details as the Departments monitor industry's implementation of the schema.

A few commenters cautioned against utilizing overly rigid filtering requirements to determine whether a specific provider is unlikely to be reimbursed for an item or service. This is because a highly granular NPI level reporting would require splitting apart NPI array values and would significantly fragment the provider references attribute, particularly where a multi-specialty physician group shares a set of negotiated rates and is represented by a single provider reference object in the file.

The Departments agree that the requirement to exclude unlikely provider-rate combinations may increase the technical complexity for reporting. Nevertheless, the Departments have determined that achieving the stated transparency goals of these rules requires this increased accuracy. The Departments intend to provide guidance for satisfying the requirement to exclude unlikely provider-rate combinations when contracts are negotiated for multiple provider groups through future technical implementation guidance in collaboration with industry to determine the most efficient approach.

Many commenters opposed the proposal to require plans and issuers to exclude unlikely provider-rate combinations because of operational challenges and burden. Several of these commenters noted that many plans do not use a uniform specialty-to-billing-code rule for all providers that can easily be repurposed into machine-readable file filtering, which could lead to unintentionally excluding meaningful provider-rate combinations. Additionally, these commenters noted that some plans and issuers do not have taxonomy code-based claims systems (using the location of care, instead, for example) or that this logic is held by payment integrity vendors instead of the plan or issuer, and creating a logic to capture the many nuances in claims adjudication possibilities would lead to a complex and resource-intensive undertaking to both develop and maintain on an ongoing basis. A commenter explained that the applicability of NUCC taxonomy codes in claims adjudication may involve complex branching logic based on factors such as whether the rendering clinician is a physician or a non-physician practitioner, and whether the clinician is double board certified. Another commenter noted that claims adjudication relies on a combination of historical utilization patterns, adjudication rules, and post-service validation, and not a static, pre-service determination of which provider types may bill for a given code. A commenter identified State requirements which may require customization for a single issuer's inclusion/exclusion of certain provider-rate combinations. Another commenter recommended that plans be permitted to use third- party data vendors or clinical appropriateness engines--not just their adjudication system--to identify and suppress irrelevant provider-rate combinations.

The Departments recognize that there is no uniform claims adjudication system and that plans and issuers may have different approaches to ensuring that claims are not approved for items or services that are not furnished by a provider in an appropriate specialty. The Departments additionally understand that claims adjudication processes are not static and that a set of pre-service rules may not always align with the post-service result when applied to a claim. However, the Departments understand that all plans and issuers include as part of their claims adjudication process a method for determining 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, even though not all of these methods are organized as taxonomies that match billing codes with specialty codes. For example, the Departments expect that every plan and issuer has a process to ensure that it does not approve a claim for heart surgery performed by a podiatrist when the claim is otherwise identical to one submitted by a cardiac surgeon.

To account for the fact that some plans and issuers use internal rules other than a provider taxonomy 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 are finalizing paragraph (b)(1)(i)(F) to specify that a plan or issuer must exclude from its In-network Rate File provider-rate combinations for items or services that are unlikely to be reimbursed based on the provider's specialty according either to 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 during the claims adjudication process. The Departments are also finalizing redesignated paragraph (b)(2)(ii) to specify that the Taxonomy File must include a plan 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 given the provider's specialty.

For plans and issuers using internal rules other than a provider taxonomy for determining whether to deny reimbursement due to provider specialty, the Departments expect that each method can be mapped to pairings of items and services with provider specialties, such that the plan or issuer can comply with the requirement to provide a Taxonomy File, as described in redesignated paragraph (b)(2)(ii). This mapping process will allow custom, internal provider taxonomies or other internal rules used to deny reimbursement given the provider's specialty, which may vary widely across plans and issuers, to be disclosed in a standardized format. As such, the Departments are requiring plans and issuers to document in the Taxonomy File a mapping of the relationships between items and services and provider specialties utilized in the claims adjudication process to the appropriate billing code and NUCC code, respectively, so file users can understand their unique approach to

excluding unlikely provider-rate combinations.

The Departments recognize that plans and issuers will incur a burden associated with establishing a system and process to remove unlikely provider-rate combinations from the In-network Rate File. However, based on comments, the Departments have determined that the collective benefits to file producers and users from reduced file sizes and increased clarity and usability significantly outweigh the burdens incurred, as discussed in sections IV.B.5. and V.D. of this preamble, and reduced file size is a goal for which many interested parties, including plans and issuers, have advocated since the first machine- readable files were published.

The Departments illustrate below how the excluded provider-rate requirement would work vis-[agrave]-vis the Taxonomy File in the scenario raised by commenters wherein a plan's or issuer's adjudication process relies on a combination of historical utilization patterns, adjudication rules, and post-service validation and not a static, pre- service determination of which provider types may bill for a given code.

The Departments agree that adjudication systems differ and often leverage dynamic rules engines, clinical edit software, and post- service validation rather than static, provider specialty lookup tables for each specialty and billing code combination. However, the goal of the Taxonomy File requirement is not to require plans and issuers to change their claim adjudication systems, nor is it to establish a standard system for denying reimbursement based on billing code- specialty pairings. Rather, the Taxonomy File is designed to provide consumers of the machine-readable files with a standardized legend to interpret the rules logic applied within the In-network Rate File.

Plans and issuers maintain the foundational data necessary to create the baseline Taxonomy File through things like provider credentialing records (which includes NPI and NUCC codes), pre-service determination or claim edit configurations, and historical claim databases. Where a plan relies on post-service adjudication, dynamic logic, or location of care, for example, rather than explicit taxonomy specialty edit rules, the plan can leverage the same empirical utilization patterns (for example, a 12-month lookback of historical claims data) combined with provider credentialing taxonomy sets to generate the required provider specialty-billing code pairings for the Taxonomy File.

As an example, consider a plan or issuer that uses any combination of the following: mapping internal provider types to NUCC taxonomy codes; performing empirical analysis on historical claims data; and extracting explicit provider specialty deterministic claim edit rules or other claim edit rules that work to ensure that a provider is not reimbursed for furnishing an item or service that is inappropriate given the provider's specialty. To create a Taxonomy File from these internal rules, the plan or issuer would need to take the following steps. First, the plan or issuer would need to derive specialty to billing code combinations from any internal rules it uses to determine whether to deny a claim for an item or service because it was not furnished by a provider in an appropriate specialty. Then, the plan or issuer would need to create a Taxonomy File from the derived output by mapping the specialty to billing code combinations to pairings of NUCC codes and billing codes.

As another example, for a plan or issuer that uses a payment integrity vendor or a clinical appropriateness engine as part of its claims adjudication process to deny reimbursement for an item or service because it was not furnished by a provider in an appropriate specialty, the taxonomic rules used by the vendor or engine are part of the plan's or issuer's internal provider taxonomy or other internal rules. Accordingly, any provider-rate combinations for items or services that are unlikely to be reimbursed given that provider's specialty pursuant to the vendor's or the clinical appropriateness engine's taxonomic rules must be excluded from the In-network Rate File. Similarly, those items or services and provider specialty combinations must be mapped to the appropriate billing code and baseline NUCC code and disclosed in the Taxonomy File. Note that, as discussed above, if the payment integrity vendor's or clinical appropriateness engine's rules used as part of the claims adjudication process are not already organized to associate items and services with provider specialties, those associations would first need to be derived from the rules before they can be mapped to billing codes and NUCC codes. The Departments expect the plan or issuer to work with such vendors to support the disclosure requirements. This may require contractual agreements between the parties to produce the required data in accordance with the required cadence. If a plan or issuer does not use a vendor or clinical appropriateness engine as part of its claims adjudication process for those purposes, then those tools are not part of the plan's or issuer's internal provider taxonomy or other internal rules and must not be used to determine which provider-rate combinations to exclude from the In-network Rate File or which billing code-NUCC code pairings to include in the Taxonomy File.

In response to the commenter who noted that State requirements may require customization for an issuer's inclusion or exclusion of certain provider-rate combinations, the Departments assume that a 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 account for applicable State requirements that require or prohibit reimbursement for an item or service due to the specialty of the provider that furnished it. The Departments expect that those requirements must inform the plan's or issuer's provider-rate exclusions, and therefore they must be appropriately represented in the Taxonomy File.

If the Departments become aware that there are plans and issuers whose claims adjudication processes do not have a way to deny reimbursement for an item or service because it was not furnished by a provider in an appropriate specialty, or whose internal provider taxonomy or other internal rules used to determine if the plan or issuer should deny reimbursement for an item or service given the provider's specialty cannot be mapped to unlikely provider-rate combinations or billing code-NUCC code pairings, the Departments will reconsider these requirements in the future to determine how such plans and issuers can comply.

Many commenters also opposed the proposal to require plans and issuers to exclude unlikely provider-rate combinations because of the potential to leave file users confused and confronted with incomplete information. A commenter advised that a provider contract may include a global list of rates even though a provider only submits claims for some of the items and services on the list. The commenter described this as an example of a permissive taxonomic mapping where a plan or issuer contracts with a multi-specialty provider group for all service codes that would likely need to be included to accommodate the wide range of services potentially delivered. Another commenter demonstrated that these exclusions would hide rate negotiations and make it harder for the public to understand contracts between

payers and providers. A commenter noted that removing such combinations increases the likelihood that consumers may be incorrectly informed that a provider is out-of-network. Another commenter cited evidence from current machine-readable file data indicating that a taxonomy-only approach can be simultaneously over-inclusive and under-inclusive because specialty labels are imperfect proxies for actual service delivery patterns. Another commenter advised the Departments to conduct an analysis to better understand the implications of removing provider- rate combinations based on plans' and issuers' internal taxonomy mapping on data quality and variance. A commenter recommended that the Departments not finalize any exclusion requirements and leave it to individual file users to apply plans' and issuers' Taxonomy Files to the In-network Rate Files to map out unlikely provider-rate combinations.

The Departments recognize the possibility of permissive taxonomic mappings that may over-include provider specialties and claims adjudication systems and the potential for over- and under-exclusion of unlikely provider-rate combinations. However, the Departments note that, if a plan or issuer does maintain a permissive taxonomic mapping, it will be revealed in the Taxonomy File and potentially verified with the Utilization File. For example, under the current reporting requirements, a plan or issuer may include a negotiated rate in the In- network Rate File for a podiatrist to perform a heart surgery even though the plan's claims adjudication system would be unlikely to process a reimbursement for that provider-service combination. Under these final rules, that provider-rate combination would likely appear in the Taxonomy File but would likely be excluded from the In-network Rate File because the plan's or issuer's internal provider taxonomy or other rules used during the claims adjudication process would likely not match podiatrists with heart surgery for purposes of reimbursement.

This excluded provider-rate combination would also be unlikely to appear in the Utilization File because it is unlikely a podiatrist would have performed a heart surgery and been reimbursed for it. File users can use the Utilization File to verify whether a plan or issuer improperly excluded provider-rate combinations from the In-network File. Specifically, if a file user identifies in the Utilization File providers that were reimbursed (or would be reimbursed but for cost- sharing liability, a modification from the proposed rule discussed in section III.C.8.b. of this preamble) for items or services for which they submitted claims during the plan or policy year, and these provider-rate combinations were included in the Taxonomy File but excluded from 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. Additionally, the Departments note that the Utilization File is one tool for determining whether a provider is correctly identified as in-or out-of-network, alongside existing provider directories and other resources, and therefore requiring the removal of unlikely provider-rate combinations should not result in consumers receiving incorrect provider network information.

The Departments acknowledge that requiring plans and issuers to remove unlikely provider-rate combinations from the In-network Rate File could diminish the public's understanding of contracts between plans and issuers and providers. However, as discussed in the 2020 final rules, the In-network Rate File is meant to capture “rates that are used to determine cost-sharing liability, which is essential information upon which consumers would need to rely to make health care purchasing decisions,” \56\ and not necessarily every component of a contract. Removing unlikely provider-rate combinations is expected to help achieve that goal, as it will reduce file size which will make it easier for users of the file to obtain the rate information necessary to make informed health care purchasing decisions.

\56\ 85 FR 72158, 72227 (November 12, 2020).

The Departments do not agree that it is necessary to conduct an analysis of the impact of requiring plans and issuers to exclude unlikely provider-rate combinations and are instead taking into account information submitted by several commenters who conducted this type of analysis and revealed, in their comments to the proposed rules, significant file size reductions. As discussed in section IV.B.5. of the Collection of Information Requirements of these final rules, the Departments expect plans (or TPAs on behalf of plans) and issuers to be able to rely primarily on data they already maintain including listing their in-network providers together with the specialties of those providers, as well as the internal provider taxonomy or other internal rules used to determine if the plan or issuer should deny reimbursement for an item or service given the provider's specialty, which are needed to map provider specialties to the appropriate billing codes, as well as similar logic implemented within their claims adjudication systems to pend or deny claims that fall outside a provider's scope of practice. The Departments disagree that individual file users should have to apply Taxonomy Files to In-network Rate Files as an alternative to requiring plans and issuers to exclude unlikely provider-rate combinations, as this would retain large file sizes and impose unnecessary barriers to file users, who may not have the technological resources to conduct manual exclusions.

A few commenters noted that many health plan and issuer cost estimator tools rely on In-network Rate Files to provide personalized cost information to consumers and requested that any provider-rate exclusions applied to the In-network Rate File (by any approach) also apply to issuers' cost calculator tools. A commenter requested that the Departments allow plans and issuers to respond to the excluded provider-service requests with a clear, consumer-friendly message indicating that an estimate is not available for that provider-service pairing.

The 2020 final rules, as well as these final rules, do not require plans and issuers to use the data in the machine-readable files to generate cost-sharing estimates for the internet-based self-service tool. The results the internet-based self-service tool should generate are highly dependent on changing inputs (network status, deductible progress, etc.). The internet-based self-service tool's outputs are required to be accurate at the time of the participant's, beneficiary's, or enrollee's request under 26 CFR 54.9815-2715A2(b)(1), 29 CFR 2590.715-2715A2(b)(1), and 45 CFR 147.211(b)(1), whereas the In- network Rate and Allowed Amount Files will not reflect changes until the next quarter. As such, an internet-based self-service tool that relies on the latest file may be inaccurate during the three-month period between postings. If a plan or issuer chooses to utilize their machine-readable files to generate results for the internet-based self- service tool, they are still obligated to ensure that the information required to be disclosed to participants, beneficiaries, and enrollees is accurate at the time the request is made. The Departments expect that each plan's or issuer's internet-based self-service tool will provide accurate responses, including not listing providers in search results for services those providers would not render, regardless of what information appears in the machine-readable files.

Many commenters urged the Departments to consider alternative

approaches to removing unlikely provider-rate combinations, including, (1) several versions of a CMS-standardized specialty-to-code framework, (2) a hybrid approach combining TIN-level claims-based inclusion with provider specialty backstops and a more general exclusion process based on prior claims volume that would appear in the Utilization File, (3) adding a fee schedule object to the In-network Rate File schema which would expose the contractual relationship that produces unlikely provider-rate combinations, and (4) a mechanism which encompasses the scope of different provider specialties and which account for the evolving nature of health care service delivery. A few commenters expressed concern that regulators, brokers, and other data users may reach differing conclusions regarding whether plans and issuers are excluding the correct provider-rate combinations without a standardized exclusion policy. A few commenters requested that the Departments consider a standardized approach after monitoring the approaches plans and issuers use to determine which provider-rate combinations to exclude. A few commenters (both for the Excluded Provider Information and the Utilization File proposals) suggested limiting or excluding provider-rate combinations to those supported by at least one fully adjudicated claim within a specified lookback period or some variation of a claims-utilization based exclusion approach. The Departments address these comments in Alternatives Considered in section V.E.2. of this preamble.

The Departments disagree that the alternative approaches to removing unlikely provider-rate combinations would be effective. In section III.C.8.c. of this preamble, the Departments discuss why a CMS- standardized approach is unworkable at this time while acknowledging they intend to analyze the landscape of Taxonomy Files to determine if greater standardization is feasible and desirable in the future. The Departments have determined that a top-down standardized approach would result in under- and over-exclusions, which many commenters warned against, by trying to impose a one-size-fits-all approach on the significant differences among plans' and issuers' taxonomic and claims adjudication systems. The Departments also discuss the limitations of a claims-based process, which would include a hybrid approach, in section V.E.2. of this preamble. The Departments disagree with adding a fee schedule object to the In-network Rate File as it would not result in the desired file size reductions that excluding unlikely provider-rate combinations should achieve. The Departments will provide examples of excluding unlikely provider-rate combinations in technical implementation guidance and will continue to work with interested parties in the schema development process to support plans and issuers and file users in understanding how to implement this requirement. 6. Out-of-Network Allowed Amount Machine-Readable File

The Departments proposed to make several amendments to the Allowed Amount File provision at 26 CFR 54.9815-2715A3(b)(1)(ii), 29 CFR 2590.715-2715A3(b)(1)(ii), and 45 CFR 147.212(b)(1)(ii) to increase the amount of historical out-of-network claims data disclosed in the files, including a proposal to lower the threshold for including claims from 20 to 11 different claims per item or service, a proposal to increase the reporting period from 90 days to 6 months, a proposal to increase the lookback period from 180 days to 9 months, and a proposal to require reporting at the health insurance market level, rather than the plan or policy level. The Departments also proposed to remove the phrase “and provider” from paragraph (b)(1)(ii)(C) to clarify that the claims threshold pertains to the number of claims for an item or service overall for the file, not the number of claims for an item or service from a particular provider. Lastly, the Departments proposed to make conforming amendments in paragraphs (b)(1)(ii)(A) through (C) to indicate that each Allowed Amount File for a given health insurance market must include information aggregated across the coverage options offered by the plan or issuer in that market, rather than all coverage options offered by the plan or issuer. The Departments solicited comments on these proposed amendments. Many commenters generally supported the proposed changes to the Allowed Amount File, noting that they would increase the amount and usefulness of out-of-network claims data. Commenters expressed that these changes would enhance transparency, improve the usability and organization of the machine- readable files, and provide more meaningful visibility into out-of- network reimbursement patterns at the market level. The Departments agree with these commenters. After consideration of public comments, the Departments are finalizing these amendments as proposed. A discussion of the specific proposed changes to the Allowed Amount File and comments received is below. a. Reducing the Claims Threshold

Since the publication of the 2020 final rules, the Departments have received feedback and observed that many plans and issuers produce Allowed Amount Files with limited to no out-of-network claims data, which the Departments have determined is due in part to the 20-claims threshold. Given the limited data available, file users are unable to perform meaningful analyses using out-of-network data.\57\ This is because there are too many “gaps” in out-of-network data in the file, which occur whenever there are fewer than 20 claims for a specific out- of-network item or service for a given plan.

\57\ Matthew Robben, Learnings from MRF Land, Serif Health Blog (October 18, 2022), available at https://www.serifhealth.com/blog/learnings-from-mrf-land.

Therefore, to increase the volume of allowed amount data available, the Departments proposed to amend paragraph (b)(1)(ii)(C) to lower the minimum claims threshold for a particular item or service under a single plan or coverage to 11 different claims for a particular item or service in a single health insurance market. As the Departments explained in the preamble to the proposed rules,\58\ the proposed 11- claims threshold aligns with the CMS cell suppression policy, which sets minimum thresholds for the display of CMS data by researchers or other custodians of CMS data sets, such as Limited Data Set (LDS) files.\59\ The policy stipulates that no cell (such as admittances, discharges, patients, services, etc.) containing a value of 1 to 10 can be reported directly.\60\ This policy is a safeguard designed to prevent the identification of individual Medicare or Medicaid beneficiaries when CMS data is shared publicly \61\ and helps ensure compliance with Federal privacy laws, such as the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule,\62\ by reducing the risk of re-

identification of individuals from aggregated data.

\58\ 90 FR 60432, 60454-55 (December 23, 2025).

\59\ Centers for Medicare & Medicaid Services, Requesting Limited Data Set (LDS) Files, available at https://www.cms.gov/data-research/files-for-order/data-disclosures-and-data-use-agreements-duas/limited-data-set-lds (last modified Mar. 16, 2026); Research Data Assistance Center (ResDAC), CMS Cell Size Suppression Policy (January 26, 2024), available at https://resdac.org/articles/cms-cell-size-suppression-policy.

\60\ Id.

\61\ Id.

\62\ 45 CFR part 160 and subparts A and E of part 164.

Many commenters supported the proposed 11-claims threshold. Several commenters noted that these changes address current data sparsity and would make it easier for plans and issuers to meet reporting requirements, improving the analytical usefulness of out-of-network disclosures and providing more complete insight into pricing patterns that directly affect patient financial exposure. A few commenters supported the proposed clarification that the claims threshold applies to the particular medical item or service that is furnished, and not the particular provider furnishing the service.

The Departments agree with these points in favor of the lowered claims threshold. As noted in the proposed rules, lowering the claims threshold will increase the volume of allowed amount data available and offer a new insight into the health care expenditures for out-of- network rates. The Departments also agree with commenters who supported the removal of “and provider” from the parenthetical language in paragraph (b)(1)(ii)(C). As noted in the proposed rules, this technical amendment will more clearly specify that the claims threshold pertains to the number of claims for an item or service overall for the file, not the number of claims for an item or service from a particular provider.

Several commenters opposed lowering the minimum claims threshold out of concern that it would increase the risk of re-identification for less frequently utilized, highly specific services, particularly in thinly populated geographies or small, specialized markets. A few of these commenters recommended the Departments establish necessary guardrails that protect patient privacy within low-volume markets. A commenter specifically recommended excluding markets or small self- insured plans with fewer than 300 enrollees. A commenter warned that plans and issuers may face additional expenses for enhanced cybersecurity measures and compliance with data privacy regulations if the Departments finalize the lower claims threshold. The commenter stated that plans and issuers would be required to ensure that their de-identification logic is updated for the 11-claims threshold in a manner that complies with the HIPAA Privacy Rule standards. Another commenter warned that lowering the claims threshold would significantly expand the data required to be disclosed and doing so would require substantial new quality assurance, system, and processing changes that would impose a large administrative burden.

The Departments acknowledge the concerns regarding privacy risks with the lowered claims threshold in the Allowed Amount File; however, as noted in the proposed rules, the Departments have determined that the proposed 11-claims threshold, when combined with the proposal to require aggregating data by health insurance market type, provides sufficient protection against the disclosure of sensitive patient information. The Departments appreciate the recommendation to establish additional guardrails for the purposes of privacy protections, but note that, as specified in current paragraph (b)(1)(ii)(C), disclosure of such information is not required if doing so would violate applicable health information privacy laws. This is consistent with paragraph (c)(3), which specifies that, among other things, nothing in 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3, or 45 CFR 147.212 alters or otherwise affects a plan's or issuer's duty to comply with requirements under other applicable State or Federal laws, including those governing the privacy or security of information required to be disclosed under this section. The Departments expect that the same data protections measures, including any cybersecurity safeguards and privacy compliance processes currently implemented to support existing disclosure requirements, will apply to the revised 11-claims threshold. Lowering the threshold does not necessitate the use of fundamentally different cybersecurity controls or substantial modifications to existing de- identification methodologies, as plans and issuers are already required under paragraph (c)(3) to maintain processes designed to comply with applicable privacy and security requirements, including those related to the protection of protected health information (PHI) and personally identifiable information.

Additionally, the Departments expect that lowering the threshold will require only limited operational changes because plans and issuers currently maintain systems and automated processes that identify and suppress data based on claim-count thresholds. Revising the threshold from its current level to 11 claims will generally require an update to existing threshold logic rather than the implementation of new systems or disclosure frameworks. Accordingly, the Departments have determined that this change will not result in additional burdens related to quality assurance, systems development, processing modifications, or administrative work beyond what is necessary to update existing operational processes.

A few commenters supported the proposal to lower the claims threshold but recommended further reducing the threshold to one claim. These commenters expressed concern that the reduction to 11 claims does not go far enough and would exclude some of the most expensive items and services which are often of interest to policymakers and researchers. A commenter recommended that the Departments require plans and issuers to segregate items and services billed by providers from items and services billed by facilities in the Allowed Amount File, noting that out-of-network facilities are generally not paid in the same way as out-of-network providers. Another commenter warned that with a lower claims threshold, Allowed Amount Files may include small claims counts and isolated high cost or atypical claims, which could introduce the risk of outlier-driven distortions. The commenter recommended that the Departments ensure there are methodological safeguards to prevent these distortions, which the commenter suggested could mislead consumers or third-party analysts.

The Departments decline to adopt a lower claims threshold than 11. The disclosure of out-of-network claims data with 10 or fewer claims may risk the exposure and identification of sensitive information, including patients' PHI, particularly when combined with other publicly available data. The Departments have determined that a claims threshold of 11, in addition to aggregating by health insurance market type and increasing the lookback and reporting periods, strikes the appropriate balance between preventing the disclosure of PHI and other sensitive information and ensuring the Allowed Amount File has a sufficient volume of data.

For segregating items and services billed by providers, while the Departments acknowledge there may be differences in payments between out-of-network providers and out-of-network facilities, the Departments decline to adopt this recommendation and note that the current Allowed Amount schema captures the place of service and also whether an item or service is furnished either by a provider (“professional”) or at a facility (“institutional”). That information should allow file users to analyze and compare allowed amounts and billed charges for items and services furnished by out-of-network providers against

those for items and services furnished by out-of-network facilities.

For the concern that small claims counts may distort the data, while the Departments recognize that file users use this data to conduct market analyses and that there may be unanticipated effects from the reported claims, the objective of these final rules is to enhance transparency by presenting actual payment amounts as they occur, without applying additional analyses. The Departments have determined that researchers and other file users are best positioned to identify which analytical methods are most appropriate for their needs, including whether those methods should suppress outliers or other extreme values. Additionally, the Departments have determined that the benefit of protecting against the disclosure of sensitive patient information outweighs the risk of potential impacts on market analyses. However, the Departments will monitor the effects of the lowered claim threshold and may consider revisiting this in the future. b. Increasing the Reporting Period

The Departments also proposed to amend paragraph (b)(1)(ii)(C) to specify that group health plans and health insurance issuers would be required to include in the Allowed Amount File allowed amounts and billed charges with respect to covered items or services furnished by out-of-network providers during the 6-month time period that begins 9 months prior to the publication date of the file. This amendment would increase the reporting period from 90 days to 6 months and increase the lookback period from 180 days to 9 months. By approximately doubling the reporting period from 90 days to 6 months and increasing the lookback period by about 50 percent from 180 days to 9 months, the Departments expect that more out-of-network claims for items and services will meet the required threshold for reporting requirements, meaning there would be more data to populate the Allowed Amount Files.

The Departments sought comment on all aspects of this proposal. The Departments were particularly interested in feedback on the impact of the proposed amendment to the required reporting cadence (proposed to be quarterly as discussed in section III.C.10. of the proposed rules) on the proposed changes to the lookback period. For example, since the proposed quarterly reporting period would require reporting 6 months' worth of data every 3 months, the Departments sought comment on whether a potential duplication of out-of-network allowed amounts across multiple files would present any difficulties for the analysis of the data, such as calculating averages or annual amounts.

The Departments received several comments in favor of this proposal. These commenters pointed out that expanding the lookback and reporting periods would likely substantially increase the number of claims that meet the reporting threshold, significantly improving the robustness of the Allowed Amount File and providing a more complete insight into pricing patterns that directly impact patient financial exposure. A commenter, however, noted that while longer reporting periods may increase dataset size, they do not automatically enhance decision relevance and may include outdated payment dynamics. Another commenter recommended a longer reporting period of 1 year and lookback period of 15 months. A few commenters also recommended that the Departments provide implementation guidance to ensure plans and issuers can produce the allowed amount data consistently and file users can interpret overlapping periods appropriately.

The Departments agree with commenters that expanding the lookback and reporting periods will increase the amount of data reported in the Allowed Amount Files and provide a better insight into out-of-network pricing in the market. The Departments note that the Allowed Amount File is designed to provide a retrospective reporting of actual billed charges as opposed to the In-network Rate File which is designed to provide prospective pricing information. As a result, data staleness presents less concern for the Allowed Amount File because it reflects historical transactions, whereas contract dynamics and negotiated rates may evolve over time. The Departments have therefore determined that an extended reporting period of 6 months is necessary to address the current data sparsity in the Allowed Amount File. By increasing the existing reporting period from 90 days to 6 months and the lookback period from 180 days to 9 months, the Departments are attempting to account for variations that may exist in the reimbursement of out-of- network providers and to make the data more useful without imposing significant additional burden on plans and issuers. The Departments will continue to monitor the amount of data being disclosed and its accuracy with the new reporting period and lookback period and other changes finalized to determine if additional adjustments may be needed in the future.

In addition, shortly after the publication of these final rules, the Departments intend to release Schema version 3.0, which will include revised technical specifications to support the amendments finalized in these rules. c. Aggregating Data by Requiring Reporting by Market Type

The Departments proposed to amend the introductory language in paragraph (b)(1)(ii) to require plans and issuers to report allowed amounts and historical billed charges at the health insurance market level, rather than for each plan or policy the plan or issuer offers.\63\ Under the proposal, plans and issuers would publish one Allowed Amount File for each market in which they offer coverage, with data aggregated across the coverage options in that market. The Departments proposed definitions of “health insurance market” at 26 CFR 54.9815-2715A1(a)(2)(xi), 29 CFR 2590.715-2715A1(a)(2)(x), and 45 CFR 147.210(a)(2)(xi), as described in section III.A. of this preamble. The Departments explained in the proposed rules that this proposal would produce more populated Allowed Amount Files and improve downstream analytics and comparability of data within a given health insurance market. Additionally, the Departments explained that organizing this data by market type would reduce the total number of Allowed Amount Files and provide additional privacy protection because the data would no longer be tied as directly to a single plan or policy.\64\ At the same time, the Departments acknowledged that market- level aggregation of out-of-network allowed amount data could reduce users' ability to connect a specific allowed amount or billed charge to a particular plan or policy, although plans and issuers would still be required to identify which plans or policies were represented in each file.\65\ The Departments sought comment on this proposal, including on what additional information might be limited or lost by aggregating allowed amount and billed charges data by health insurance market type, and the potential importance of that information to price transparency.

\63\ 90 FR 60432, 60455 (December 23, 2025).

\64\ Id.

\65\ Id.

Many commenters supported the proposal to aggregate Allowed Amount File reporting by market type, stating that this approach would increase the completeness and usability of out-of-network data, while reducing

fragmentation, reporting burden, and privacy risks. Specifically, these commenters expressed that this type of aggregation would support data analysis and comparison within and across market segments. These commenters agreed that such aggregation would lower the number of files to be reported and managed. Many commenters agreed with the Departments that current, plan-level Allowed Amount Files often contain little data which hinders meaningful analysis. A few commenters supported market- type aggregation to reduce the risk that file users could identify information protected by the HIPAA Privacy Rule reported by plans with low claims volume. A commenter recommended only aggregating below an enrollment threshold to ensure appropriate safeguards for protecting privacy, rather than broad suppression of allowed amount data. A commenter noted that publishing out-of-network rates at the health insurance market level is critical to the employer's fiduciary management of their health plan and health plan administrators.

The Departments agree that shifting to aggregation by market type will lead to improvements in completeness, access, and usability of the allowed amount data, while reducing the burden on plans and issuers in developing the Allowed Amount Files. Furthermore, aggregating by market type results in fewer Allowed Amount Files, which makes the data more manageable, while enhancing analytical operation and output. The Departments also agree that aggregation of this data will help plans with low claims volume meet reporting thresholds and reduce the risk that information protected by the HIPAA Privacy Rule will be identified. The Departments have concluded that market-type aggregation, as adopted here, strikes the best balance in enhancing allowed amount data quality and usability, while appropriately protecting privacy.

A few commenters opposed the proposed requirement for plans and issuers to aggregate allowed amount data by market type. A few of these commenters expressed concern that separating out-of-network allowed amount data by market type may lessen the utility of having all of a health plan's or issuer's data in one file, and that without clear standardized definitions, may make it difficult to assess how aggregation would affect data usability and comparability. A commenter noted that there is considerable variation of out-of-network programs and reimbursement schedules that self-insured plan sponsors may use and therefore did not agree that aggregating self-insured plan sponsors into one file would improve price transparency outcomes.

The Departments understand that aggregation of out-of-network allowed amount data, while providing many benefits, will reduce some granular details in the data, and by extension, the levels of interpretation and inference that can be drawn from the data. However, the Departments agree with the many commenters who supported market- level aggregation in the Allowed Amount Files, based on the benefits of market-level aggregation substantially outweighing any analytical downsides of such aggregation. The Departments have determined that any loss of granularity in the data, such as mapping back to specific health plans or contracts or having all of a health plan's or issuer's data in one file, does not diminish the benefits of transparency in coverage. Nevertheless, the Departments will monitor the effects of this rule change and may consider revisiting this in the future.

A few commenters emphasized that by allowing reporting by market type, allowed amount data would become more consistent and easier to leverage. One of these commenters also requested that the Departments be clear that market type was not the same as product type to ensure that the change would result in a significant reduction of files. Other commenters requested that the Departments provide clear, standardized market type definitions to ensure usability and minimize compliance variability. A commenter suggested expanding the proposed market definitions in 26 CFR 54.9815-2715A1(a)(2)(xi), 29 CFR 2590.715- 2715A1(a)(2)(x), and 45 CFR 147.210(a)(2)(xi) to include individual market, small group market, mid-market fully insured, mid-market self- insured, large group fully insured, and large group self-insured.

The Departments agree that a clear and standardized set of market type definitions is important for consistency in reporting by market type and to avoid potential confusion with product type or other standard terminology for the Allowed Amount File. As such, and as discussed in section III.A. of this preamble, the Departments proposed to define the term “health insurance market” to refer to the individual market, large group market, small group market, and all self-insured group health plans maintained by the plan sponsor (other than account-based plans, as defined in 26 CFR 54.9815-2711(d)(6)(i), 29 CFR 2590.715-2711(d)(6)(i), and 45 CFR 147.126(d)(6)(i), and plans that consist solely of excepted benefits), with each market type including its own standardized definition based largely on existing Federal regulations.\66\ As discussed in section III.A. of this preamble, the Departments are finalizing the definition of “health insurance market” with modifications to cross-reference the relevant definitions of excepted benefits for clarity at 26 CFR 54.9815- 2715A1(a)(2)(xi), 29 CFR 2590.715-2715A1(a)(2)(x), and 45 CFR 147.210(a)(2)(xi). The Departments agree that allowing reporting by market type will allow allowed amount data to become more consistent and easier to leverage. Additionally, the Departments observe that “mid-market” is a term not currently defined in Federal regulations, but is casually used in commercial health insurance parlance to denote employer group health plans that have approximately 51-250 employees.\67\ Industry distinctions between the mid-market and large group market are based primarily on differences in purchaser behaviors, and not on differences in product or network composition across these two segments. The Departments further observe that mid-market groups would be considered “large groups” under existing Federal and State definitions. To ensure consistency of definitions--and lacking specific reason to determine that adding mid-market categories would meaningfully enhance data aggregation or downstream analytics at this time--the Departments are finalizing the market-type definitions as proposed.

\66\ 90 FR 60432, 60442 (December 23, 2025).

\67\ Based on internal research, the Departments have found that variations on the term “mid-market” are used within the commercial insurance industry to refer to employer group health plans that are larger than small group plans, but that tend to be on the small side for large group plans. Different issuers and plans use varied definitions to pinpoint what would count as a mid-market group. See, for example, Sentara Health Plans, Employer Plan Sales Resources and Descriptions, available at www.sentarahealthplans.com/en/brokers/employer-plans/sales-resources-and-plan-descriptions (last visited June 1, 2026) (defining mid-market groups as having between 51 and 150 employees); BlueCross BlueShield of New Mexico, Mid-Market Group Plans, available at https://www.bcbsnm.com/producer/mid-market-group-insurance (last visited June 1, 2026) (defining mid-market groups as having between 51 and 150 employees); and Capital Blue Cross, Medium Group Plans, available at www.capbluecross.com/wps/portal/cap/employer/shop-group-plans/medium-plans/ppo-choice-select (last visited June 1, 2026) (defining “Medium Groups” as having between 51 and 99 employees).

A few commenters expressed concerns that aggregating out-of-network allowed amount data by market type would create new operational challenges, and confusion, particularly in States that require the “merging” of individual and small group markets. A

commenter noted that aggregated market reporting can improve comparability and reduce administrative complexity as long as the consolidation does not obscure meaningful variation that file users rely upon for analytic purposes. A commenter recommended the Departments provide technical guidance or standardized templates, noting that doing so would ensure consistency and reduce confusion among plans and issuers.

The Departments recognize the concern regarding the potential for aggregation to obscure variations in data and will monitor the effects of this rule change through GitHub which provides an avenue to collect ongoing input from interested parties that can inform further schema iterations. Additionally, shortly after the publication of these final rules, the Departments intend to release Schema version 3.0, which will include revised technical specifications to support the amendments finalized in these rules. The Departments understand that a “merged market” generally means that a particular State combines the individual and small group segments for certain Federal and State regulatory purposes, most commonly for creating larger risk pools to stabilize rating.\68\ However, even where a State has adopted a “merged market,” health insurance coverage generally would still fall within Federal definitions for either the individual market or the small group market for purposes of Federal law and the data from such coverage can be attributed to either the individual or small group market. The Departments have not identified a reason why data for purposes of the Allowed Amount File should be reported in a way that aligns with the way data for purposes of establishing a risk pool is reported.

\68\ Section 1312(c) of the Affordable Care Act generally requires a health insurance issuer to consider all enrollees in all health plans (except grandfathered health plans) offered by such issuer to be members of a single risk pool for each of its individual and small group markets. States have the option to merge the individual and small group market risk pools in their states under section 1312(c)(3) of the Affordable Care Act. See also 45 CFR 156.80.

A commenter suggested that adding data quality checks or validation requirements would enhance the usability and value of the out-of- network data.

The Departments acknowledge the importance of data quality checks and validation and are finalizing several changes that are expected to improve data quality and accuracy and allow additional time for data validation. For example, the Text File contact information requirement enables file users to more easily report issues and receive responses, as discussed in section III.C.8.d. of this preamble. The Departments are also finalizing a quarterly reporting cadence for In-network Rate and Allowed Amount Files, which several commenters noted will provide plans and issuers additional time for validation and quality assurance before posting, as discussed in more detail in section III.C.11. of this preamble. The Departments continue to solicit regular feedback from the community on data quality and validation issues and may consider including additional quality improvement measures in future guidance or rulemaking.

A few commenters requested that the Departments clarify how the independent dispute resolution (IDR) process decisions and awards should be represented in the files, cautioning that overly broad or unclear rules could undermine transparency and comparability.

The Departments appreciate the suggestion and will consider addressing this issue in future iterations of the technical implementation guidance. The Departments also note that IDR payment determinations are already subject to a different set of public use file disclosures under the No Surprises Act. Therefore, requiring plans and issuers to add this additional data to the Allowed Amount Files would be unnecessarily burdensome.\69\

\69\ Code section 9816(c)(7), ERISA section 716(c)(7), and PHS Act section 2799A-1(c)(7); see also Independent Dispute Resolution Reports, available at https://www.cms.gov/nosurprises/policies-and-resources/reports.

A commenter suggested including information in the files on insurer revenue generated from out-of-network contracting, leased networks, or other negotiations. Another commenter recommended linking the out-of- network allowed amount data with additional network identifiers and plan information noting that product types are not always defined consistently across the industry.

The Departments appreciate the commenters' suggestions for additional information to be included in the Allowed Amount File and will monitor the effects of this rule change, including potentially adding data elements in the future, but have determined they are out of scope and decline to adopt these recommendations in these final rules.

A commenter suggested that geographic normalization of out-of- network allowed amount data is important to any downstream analytics comparing data across regions. Consequently, the commenter advocated for reporting reforms to ensure that geographic identifiers in the data are sufficient to allow for meaningful comparisons, while avoiding excessive granularity.

The Departments generally recognize the importance of geocoding in allowed amount data, to support a range of downstream analytics that may be important for price transparency. However, current Allowed Amount File requirements at paragraph (b)(1)(ii)(C)(2) specify that each unique allowed amount included in a file must be associated with the NPI, TIN, and Place of Service Code for a corresponding out-of- network provider. The Departments have determined that the latter requirement already imposes meaningful geocoding on individual observations within allowed amounts data, since the NPIs and TINs are associated with providers who have specific locations of practice in the real world. Therefore, the Departments are not finalizing any changes to the geocoding requirements within the Allowed Amount File at this time. Going forward, the Departments will continue to solicit regular feedback from file users on specifications for the Allowed Amount File, including with regard to the adequacy of geocoding for specific downstream use cases. 7. Attestation

The Departments are finalizing at new 26 CFR 54.9815- 2715A3(b)(1)(iv), 29 CFR 2590.715-2715A3(b)(1)(iv), and 45 CFR 147.212(b)(1)(iv) a requirement that a group health plan or health insurance issuer must attest, for each machine-readable file required under paragraphs (b)(1)(i) through (iii) and (b)(2)(i) and (ii) of these sections, that, to the best of its knowledge and belief, the plan or issuer has included all applicable information in accordance with the requirements of 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3, and 45 CFR 147.212, as applicable, and the information encoded is true, accurate, and complete as of the date in the file. This attestation requirement would go into effect in accordance with the applicability dates specified in 26 CFR 54.9815-2715A3(c), 29 CFR 2590.715-2715A3(c), and 45 CFR 147.212(c).

Of the commenters who addressed compliance and enforcement of Transparency in Coverage requirements, many requested that the Departments require plans and issuers to attest to the accuracy and completeness of their machine-readable files. Most of these commenters pointed to the existing Hospital Price Transparency requirement at 45 CFR 180.50(a)(3) as a model, both as an important compliance

and enforcement policy and also to further the goal of Executive Order 14221 to ensure that “pricing information is standardized and easily comparable across hospitals and health plans.” \70\ These commenters noted that an attestation requirement creates a clear, objective compliance signal that reduces ambiguity for both payers and regulators. Several commenters emphasized that their ongoing analyses of machine-readable files from a wide variety of plans and issuers reveal consistent accuracy concerns, and requiring attestations would lead to more reliable files in the future. A commenter noted that after processing thousands of files they identified conflicting rates, missing providers, missing billing codes, and inconsistent network identifiers. Commenters referred to a January 2026 report from the State of Indiana \71\ which identified issues in the machine-readable files including unnecessary duplication, multiple rate schedules for the same provider, multiple rates for the same services, missing or incorrect data, and invalid/non-standard codes. A few commenters added that plan and issuer attestations would better enable employers to rely on these disclosures when negotiating contracts and evaluating performance. Several commenters also proposed that the Departments require plans and issuers to attest to the accuracy of their machine- readable files, including through existing reporting channels like Form 5500 or similar established ERISA reporting. A few commenters suggested expanding use of the validator tool the Departments provide as part of their technical implementation guidance to assist with attestation.\72\

\70\ Exec. Order No. 14221, 90 FR 11005 (February 28, 2025).

\71\ Sachdev G, Lambert H. Re: Response to Executive Order 25-21 Increasing Freedom and Opportunity for Hoosiers by Improving Price Transparency in Healthcare, Indiana Department of Insurance (January 21, 2026), available at https://www.in.gov/gov/files/E.O.-25-21-Memo,-Executive-Summary,-and-Study.pdf.

\72\ See Centers for Medicare & Medicaid Services, Price Transparency Guide Validator, GitHub, https://github.com/CMSgov/price-transparency-guide-validator (last accessed May 13, 2026).

The Departments agree that an attestation requirement will improve the accuracy and reliability of the disclosures in the machine-readable files and promote better alignment between hospital and plan and issuer pricing disclosure requirements. It is also a logical extension of the proposals related to improving the accuracy of public pricing disclosures, and will help fulfill the objectives of Executive Order 14221. As several commenters noted, Executive Order 14221 tasks the Departments with ensuring price transparency reporting is “complete, accurate, and meaningful,” as well as “standardized and easily comparable across hospitals and health plans.” \73\ Consequently, the proposed rules were designed to “improve the standardization, accuracy, and accessibility of public pricing disclosures in line with the goals of the Executive Order 14221.” Requiring plans and issuers to attest to the accuracy of their machine-readable files, to the best of their knowledge, is an extension of those proposed rules, and several commenters made it clear that they understood such a requirement would achieve this alignment. Furthermore, one of the goals of the proposed rules was to align the Hospital Price Transparency reporting requirements with Transparency in Coverage requirements for plans and issuers.\74\ The Hospital Price Transparency reporting requirements contain an attestation requirement,\75\ and, therefore, including a similar attestation requirement does not go beyond what is required in the Hospital Price Transparency reporting requirements. The Departments do not agree that Form 5500 or similar ERISA reporting requirements are appropriate, as they apply only to a subset of plans that are subject to these final rules. The Departments continue to update and make available the validator tool, but are not requiring it as part of the attestation, as it does not test the accuracy of the data in the schema but instead validates that the files are formatted correctly.

\73\ Exec. Order No. 14221, 90 FR 11005 (February 28, 2025).

\74\ 90 FR 60432, 60434-35 (December 23, 2025).

\75\ 45 CFR 180.50(a)(3)(iii).

A primary goal of the Federal Government's initiatives on price transparency is to ensure that the public has access to accurate and actionable pricing information. Section 1311(e)(3)(A)(i) to (viii) of the Affordable Care Act outlines specific information and data that must be submitted to the Exchange, the Secretary of HHS, the relevant State insurance commissioner, and the public on an accurate and timely basis. The 2020 final rules extensively discussed the value of accurate pricing information for consumers. Additionally, in the 2020 final rules, the Departments noted an intention to “monitor the accuracy of the information provided through third-party developers and secondary entities and take information obtained through this monitoring into account for future regulatory action or guidance, as appropriate.” \76\ Based on consistent feedback from interested parties and the Departments' internal analyses of machine-readable file data, the Departments have determined that additional regulatory action is needed to address the inaccuracies commenters detailed. The Departments note that this attestation requirement will not alter the underlying duty to disclose accurate and complete pricing information. Rather, it promotes accountability by requiring plans and issuers to certify compliance with those existing obligations. The Departments anticipate a small one-time burden to implement this requirement and low ongoing costs, as plans and issuers can automate much of the process of generating the attestation, as discussed in sections IV. and V. of this preamble.

\76\ 85 FR 72158, 72220 (November 12, 2020).

Most commenters requesting that the Departments finalize an attestation requirement suggested that the attestation occur at a plan or issuer's executive level. This includes commenters who specifically requested executive-level attestations and commenters who recommended aligning with the Hospital Price Transparency attestation requirement, which specifies in 45 CFR 180.50(a)(3)(iv) that each hospital must encode the name of the hospital chief executive officer, president, or senior official designated to oversee the encoding of true, accurate, and complete data.

The Departments have determined that, as with the Hospital Price Transparency attestation provision, requiring plans and issuers to encode the identity of a chief executive officer, president, or senior official designated to oversee the encoding of true, accurate, and complete data is a reasonable and appropriate approach to increasing public confidence in the machine-readable file disclosures, and therefore the Departments adopt the same. The Departments expect, as discussed in the 2025 Hospital Price Transparency rules, that the designated attester would, as necessary, consult with staff with direct involvement in developing the machine-readable files, in order to accurately make the required attestation.\77\ As with the Hospital Price Transparency attestation provision, the Departments' focus is on the truth, accuracy, and completeness of the pricing data included in the machine-

readable files.\78\ Accordingly, the attestation requirement applies to the In-network Rate File, the Allowed Amount File, the Prescription Drug File, the Utilization File, and the Taxonomy File, which are the files that contain pricing and plan and provider identifying data.

\77\ 90 FR 53448, 54005 (November 25, 2025).

\78\ See 45 CFR 180.50(a)(3)(iii) and (iv).

A few commenters noted a concern with requiring a group health plan sponsor or a “renter” of a provider network to attest to the accuracy of the machine-readable files, given that employers do not possess the data that is required to go into the files. These commenters recommend that where a TPA or other service provider owns, manages, or maintains the provider network and negotiated rates, the TPA or other service provider whose executives are responsible for producing the machine- readable file should be required to make the attestation.

Under these final rules, plans and issuers may contract with other parties, such as TPAs, to provide the necessary data to comply with the Transparency in Coverage requirements on the plan's or issuer's behalf, as specified in redesignated paragraph (b)(5) in these final rules. To address how those special rules would work in the context of an attestation, the Departments specify in paragraph (b)(1)(iv)(C) that plans and issuers may satisfy the attestation requirements of paragraphs (b)(1)(iv)(A) and (B) by entering into a written agreement under which another party (such as a third-party administrator) makes the attestation required in paragraph (b)(1)(iv)(A) on behalf of the plan or issuer and encodes the name of the other party's chief executive officer, president, or senior official designated to oversee the encoding of true, accurate, and complete data, only if the plan or issuer has entered into an agreement with the other party to provide the information in paragraph (b), as described in paragraph (b)(5). With respect to insured group health plans, pursuant to the special rules in paragraph (b)(5)(i), a plan sponsor may enter into a written agreement with the issuer offering the coverage that requires the issuer to provide all applicable information required under paragraph (b), including the attestation required under paragraph (b)(1)(iv)(A), on behalf of the plan. In this scenario, if the issuer fails to do so, or such information in not accurate and complete in accordance with the attestation requirements in paragraph (b)(1)(iv), then the issuer, but not the plan, would be considered to violate the transparency disclosure requirements of 26 CFR 54.9815-2715A3, 29 CFR 2590.715- 2715A3, and 45 CFR 147.212, as applicable. Alternatively, pursuant to the special rules in paragraph (b)(5)(ii), a plan or issuer may enter into a written agreement with a third party (such as a third-party administrator) that requires the third party to provide all applicable information required under paragraph (b), including the attestation required under paragraph (b)(1)(iv)(A), on behalf of the plan. In that scenario, if the third party fails to include all applicable information or such information is not accurate and complete in accordance with the attestation requirements in paragraph (b)(1)(iv), then the plan or issuer violates the transparency disclosure requirements of 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3, and 45 CFR 147.212, as applicable.

A commenter requested that the Departments make it clear that, for any government-regulated plans, disclosure of price information in the machine-readable file is material for purposes of payment and that an inaccurate machine-readable file can be a violation of the False Claims Act.

The False Claims Act is outside the scope of these final rules. 8. Contextual Files: Change-Log, Utilization, Taxonomy, and Text

In the proposed rules, the Departments proposed to require group health plans and health insurance issuers to publicly disclose, through machine-readable files, additional contextual information that would help file users better understand the public disclosures required under paragraph (b)(1)(i). These files, which include a Change-log File, Utilization File, and Taxonomy File, would contain information about the data within the In-network Rate and Allowed Amount Files. The Departments also proposed to require a contextual machine-readable file to help users find the In-network Rate, Allowed Amount, and prescription drug machine-readable files required under paragraph (b)(1) and proposed paragraph (b)(2)of this section, which the Departments proposed to identify as a Text File.\79\ In particular, the Departments proposed to amend 26 CFR 54.9815-2715A3, 29 CFR 2590.715- 2715A3, and 45 CFR 147.212 to redesignate paragraphs (b)(2) through (4) as paragraphs (b)(3) through (5), respectively, and to add new paragraph (b)(2) to require contextual files. Specifically, the Departments proposed to add new paragraphs (b)(2)(i) through (iv) requiring: a Change-log File at paragraph (b)(2)(i), a Utilization File at paragraph (b)(2)(ii), a Taxonomy File at paragraph (b)(2)(iii), and a Text File at paragraph (b)(2)(iv).

\79\ The proposed rules proposed amendments to requirements related to the prescription drug machine-readable files, specifically: the requirement that plans and issuers must include a plain text file in a .txt format in the root folder of a plan's or issuer's website as described in section III.C.7.d. of the proposed rules and the requirements related to the method and format for disclosing information to the public as described in section III.C.9. of the proposed rules.

The 2020 final rules at 26 CFR 54.9815-2715A3(b), 29 CFR 2590.715- 2715A3(b), and 45 CFR 147.212(b) require plans and issuers to make available on a public internet website the disclosure of health care pricing information in machine-readable files, in accordance with specific manner and format requirements. In particular, the Departments require plans and issuers to disclose in-network provider rates, out- of-network allowed amounts and the associated billed charges, and negotiated rates and historic net prices for prescription drugs. In the 2020 final rules, the Departments recognized the necessity of public disclosure of health care pricing information due to the variation in health care prices across the health care industry and the complexity of health insurance and health plan coverage.\80\ While the price disclosures required in the 2020 final rules offered researchers and the broader public broad insight into the previously opaque world of contracts and pricing for health care services, there were still ambiguities in the data that prevented the public from gaining a more comprehensive understanding of health care industry pricing practices. These proposed additional files would help make the data disclosures of the machine-readable files required under paragraph (b)(1) more meaningful and accessible, which would promote greater transparency in health care pricing information. Under the proposal, plans and issuers would be required to prepare a Change-log File, a Utilization File, and a Taxonomy File for each In-network Rate File prepared under the proposed rules, and a single Text File to facilitate locating the other machine-readable files required under

the proposed rules. Under the proposed rules, each Change-log File would reflect changes in data from one In-network Rate File (prepared for a specific provider network) to the publishing of the next In- network Rate File; each Utilization File would reflect utilized covered items and services under the plans and policies represented in one In- network Rate File; and each Taxonomy File would represent the mapping of billing codes to internal provider taxonomy codes used as part of the claims adjudication process for the plans and policies represented in the In-network Rate File. Each Text File would direct users to the location of the machine-readable files required under paragraphs (b)(1) and (2) and provide contact information for an individual who can address inquiries and issues related to the required machine-readable files. To ensure this data would be imported and read by a computer system directly, without reliance on proprietary software, and to promote standardization, these contextual files would also need to be machine-readable, in the form and manner specified in guidance pursuant to proposed re-designated paragraph (b)(3)(i), unless otherwise specified in 26 CFR 54.9815-2715A3, 29 CFR 2590.715-2715A3, and 45 CFR 147.212.

\80\ The 2020 final rules stated that “many consumers do not fully comprehend the basics of health coverage, much less the more complex facets of the health care system that can affect an individual's out-of-pocket cost for items and services, including: Its specialized billing codes and payment processes; the various specialized terms used in plan and coverage contracts and related documents (such as copayment and coinsurance); and the various billing and payment structures plans and issuers use to compensate providers and assign cost-sharing liability to individuals (for example, bundled payment arrangements).” 85 FR 72158, 72210 (November 12, 2020).