The Serif Health team and the larger price transparency ecosystem have eagerly awaited updated new guidance, rules, and schemas for Transparency in Coverage (TiC) throughout the year. On October 1st, schema updates were released via the CMS Transparency in Coverage schema GitHub repository...without any broader commentary, and on the same day the federal government entered a shutdown. Here's what we know - and what's still unclear.

Updates to TiC weren't completely unannounced. We participated in a formal Request for Information process over the summer along with a consortium of price transparency-focused organizations, and we collectively suggested some significant improvements to the posting structure and validation toolkit that would increase clarity, reduce bloat, and improve gaps in completeness and accuracy seen in many TiC files.

On September 16, The Departments of Health and Human Services, Labor, and the Treasury hosted a stakeholder webinar via RegTAP (Registration for Technical Assistance Portal) to preview changes to the TiC machine-readable files as part of schema version 2.0. Our team attended the call, excited to hear about what recommendations and proposals we advanced during the RFI process would be adopted.

The proposed 2.0 changes contained some thoughtful improvements: the changes should improve provider entity resolution and sponsor vs. plan naming, reduce fragility due to provider reference files, increase out-of-network data volume, and clarify DRG pricing. But there wasn’t much in the update that appeared to address our macroscopic completeness and accuracy concerns. And without enforcement, some of the changes may make finding some answers in the data more challenging.

The 2.0 updates released via GitHub reflected the RegTAP changeset, but it still isn't clear if that payload is a full and final set of changes for TiC 2.0. Given the shutdown, we aren't likely to get additional clarity anytime soon. We are keeping our fingers crossed for further updates related to completeness, accuracy, prescription drug schemas and drug pricing disclosure requirements once D.C. reopens.

Key Updates in the Schema

• Separate Provider Reference Files Eliminated
  
  A major win. This change simplifies schema complexity by removing the fragile remote referencing approach and reduces redundant inline references. If adopted as expected, this should improve consistency, reduce file sizes, and reduce broken file links.

• Severity of illness for APR-DRGs
  
  A new Severity_of_illness field for in-network rates improves specificity for APR-DRGs while cutting down on duplicate rows. This could improve how inpatient and hospital rates are represented, though in practice we don't see a ton of APR or other DRGs with complexity severities in the data.
  
  
• Business name required with EIN
  
  This closes a critical gap. Schema 2.0 requires that if an EIN is reported, the business name must be included—finally giving users a more reliable way to tie in-network rates to provider entities. This has been a headache for any stakeholder working with the data to date, and represents a significant level up for identifying the correct healthcare providers and organizations for a given negotiated rate.
  
  
• Plan Sponsor Name Separated from Plan Name
  
  A meaningful change for out-of-network rate files: plans must now report the plan sponsor name as distinct from the plan name, clarifying which employer groups are linked to which negotiated rates.
  
  
• Lowered Threshold for Out-of-Network Reporting
  
  The claim-count threshold for publishing allowed amounts dropped from 50 to 20, which should materially improve completeness across geographies and smaller provider groups.
  
  
• Greater Emphasis on CSTM-00 Place of Service Codes
  
  CMS reinforced that catch-all place of service code values (CSTM-00) may be used to reduce file size. While technically allowed before, this change formalizes the guidance—and could have tradeoffs for transparency.
  

Our Take

While new requirements like severity_of_illness and plan_sponsor_name are clear steps toward more accurate and usable data, their conditional requirement, in our opinion, will slow adoption and allow for potential gamesmanship.

For example: If “business_name” is only required for EINs, is Anthem (who only uses NPIs in the tax identifier value field) going to be required to fill in the field? Will they? What happens if several large health plans shift their reporting to NPIs to dodge the requirement of reporting names?

This isn't an idle concern. The schema documentation notes: “When a NPI number is used, it is assumed that the provider would otherwise be reporting by their social security number” - but we already know this assumption has not held true in practice. Additionally, no clarity was given about enforcement process or expectations, and toolkit updates (i.e., the schema validator) have not been released; any improvements hoped for will require some enforcement follow through to ensure adoption.

During the RegTAP call, technical advisors suggested that CSTM-00 place of service codes should be used to reduce file size. This a valid suggestion when a given code/provider combination only contains one rate and place of service string record, but in practice, our team has found that ambiguity and overlapping places of service are quite common. Use of non-standard code ranges and placeholder expansion values can make finding exact answers difficult, especially when there is no clarity around rules of precedence. If a procedure code has a negotiated rate with place of service CSTM-00 and another rate for the same code and provider exists with CSTM-00, which wins? Or, if the row is alongside multiple other fixed sets of place of service codes, which record should be considered the 'right' price to apply for services rendered in an office setting? Such values' non-specificity can mask needed decision logic, making it harder to compare rates across payers or markets. It would have been more helpful to state that if CSTM-00 is used, there should be no other variations of sites of service for the given code / provider / arrangement combination.

This is the tension at the heart of TiC: every improvement in accuracy is balanced against concessions to file size, payer compliance, and administrative feasibility. The net effect is that usability still depends heavily on how payers choose to implement these schema options, and who is reviewing and validating those postings.

Why It Matters

For any organization building on TiC data—providers, analytics vendors, care navigation platforms, payers—Schema 2.0 will change the ingestion and normalization game. Clearer sponsor fields and lower thresholds are real wins. But:

• Custom codes introduce fuzziness: While they may help limit file sizes, they might hamper the main goal in all of this–clearly answering questions about price across payers and entities.
  
  
• Toolkit and validator updates are MIA: There’s still no clarity on timing for validator updates or how these new requirements will be audited.

• Lack of completeness or accuracy tests: Without built-in tests for ensuring quality, and guardrails for enforcement, transparency still has blind spots.

This moment captures the core tension of price transparency efforts: balancing accuracy with administrative burden, openness with compliance feasibility. 

What’s Next?

We expect more updates from CMS before year’s end—including delayed guidance around prescription drug MRFs. In the meantime, Schema 2.0 gives us a new rulebook—but not yet the referee.

At Serif Health, we’re tracking how these schema changes show up in real-world MRFs across payers—and what they mean for users trying to bring clarity to care costs. We’ll continue to publish insights and highlight how these changes show up in live MRFs via our blog!

Contact us at hello@serifhealth.com