This document is submitted by the Massachusetts Health Data Consortium (MHDC) and its Data Governance Collaborative (DGC) in response to the CMS Medicare Program: Hospital Outpatient Prospective Payment and Ambulatory Surgical Center Payment Systems; Quality Reporting Programs; Payment for Intensive Outpatient Services in Rural Health Clinics, Federally Qualified Health Centers, and Opioid Treatment Programs; Hospital Price Transparency; Changes to Community Mental Health Centers Conditions of Participation, Proposed Changes to the Inpatient Prospective Payment System Medicare Code Editor; Rural Emergency Hospital Conditions of Participation Technical Correction NPRM (CMS–1786–P) posted in the Federal Register on July 31, 2023 and found here: https://www.federalregister.gov/documents/2023/07/31/2023-14768/medicare-program-hospital-outpatient-prospective-payment-and-ambulatory-surgical-center-payment

About MHDC

Founded in 1978, MHDC, a not-for-profit corporation, convenes the Massachusetts’s health information community in advancing multi-stakeholder health data collaborations. MHDC’s members include payers, providers, industry associations, state and federal agencies, technology and services companies, and consumers. The Consortium is the oldest organization of its kind in the country.

MHDC provides a variety of services to its members including educational and networking opportunities, analytics services on both the administrative and clinical side (Spotlight), and data governance and standardization efforts for both clinical and administrative data (the Data Governance Collaborative/DGC and the New England Healthcare Exchange Network, respectively).

About DGC

The DGC is a collaboration between payer and provider organizations convened to discuss, design, and implement data sharing and interoperability among payers, providers, patients/members, and other interested parties who need health data. It is a one stop interoperability resource. The DGC primarily focuses on three areas:

1. Collaboration: Development of common understanding of and specifications for data standards, exchange mechanisms, and what it means to participate in the modern health IT ecosystem
2. Education: helping members understand their regulatory obligations, the data and exchange standards they're expected to use, and modern technology and related processes
3. Innovation: Identification and development of projects and services needed to make modern health data practices and exchange a reality

General Comments

This section general comments that cross multiple questions asked by CMS or that do not have specific questions in the NPRM. MHDC is focusing on the price transparency components of the proposed rule.

Use of Encode for Entering Data into a File

Participants in our Data Governance Collaborative, particularly those who are more technical, find the use of the word encode to represent placing data into structures defined by templates a curious and potentially confusing choice. Encoding data has a very specific meaning to many people involving the translation of some or all characters included in the data into a specific code set (such as the percent/URL encoding used to represent punctuation and certain other characters in URLs or representing each character in a string as a hexadecimal or Unicode character identifier). We respectfully suggest CMS consider enter the data or format the data rather than encode the data for their proposed usage.

Machine-Readable File Definition

The proposed definition indicating a machine-readable file is a single digital file that is in a machine-readable format is a circular definition (a foo does foo, a foo is foo) and, as such, is not particularly helpful. If CMS feels it is necessary to define this term, a definition of what constitutes machine-readable that does not use the term machine-readable is necessary to have a fulsome, useful, distinct definition with real meaning.

CSV Wide vs Tall Format

The brief definitions of the CSV wide and CSV tall formats contained in the proposed rule are somewhat opaque and difficult to understand or visualize. The link provides for more information includes information about both current and proposed formats and it’s not always clear what information applies to each. The July 26, 2023 presentation slides are clearly related to the new proposals but only include examples of the CSV wide format. We respectfully suggest that if these formats are retained much more description and specific examples of both formats be included in the final rule and/or as later guidance.

Proposed General Data Elements

We agree that including metadata that better identifies the applicability and contents of a file in the file itself makes sense. Once downloaded or otherwise acquired, the file will no longer be attached to any such information supplied on the hospital’s website and likely will not be seen by those trying to parse or otherwise use the file. Further, any automated process will likely be trying to ingest or parse multiple such files; knowing exactly when each file’s data applies is critical.

However, we note that this data cannot be incorporated directly into pure CSV files and thus makes it difficult to support such formats as options for use (see our longer comment related to this below).

Consolidated Standard Charge Data

We find the proposal to combine the various standard charge data fields (gross charge, payer-specific negotiated charge, de-identified minimum and maximum charges, and discounted cash price) into a single data element perplexing. Participants in our Data Governance Collaborative agree. These are clearly identifiable separate and distinct things that are best served by being clearly identified and identifiable so they can be directly mapped in meaningful ways by people or programs using the MRF.

If using a hierarchical structure like JSON, it makes sense to group them together at a top level and then provide separate properties for each under a more general standardCharge (or similar) property, but if allowing CSV formats, there is no useful way we can determine to do this beyond imposing some type of more complex requirement for key-value pairs within that single data element (preferably with standardized names for the various keys to enable automated processing). At that point, it seems like just using separate fields would offer a better, more efficient user/computer experience.

Grouping Plans Together if Negotiated Together

When data is identical across different plans it makes sense to combine that data together. It’s more efficient, and reduces file sizes. However, we urge CMS to define a value set of specific allowed groupings that are well defined and consistent across hospitals to allow for better automated processing of these values. We understand this means that some duplication may still be required under this plan, but we feel that clarity around how to interpret groups is essential and standardization is one of the primary goals of this proposed update so standardization should be one of the criteria for judging each proposed change. It helps no one if one hospital uses “all PPO plans”, another uses “PPO”, and a third uses “Preferred Provider Organization plans” and third parties processing those files treat them as three different values.

Another issue is that this grouping may require third party users of MRFs to understand and know which plans fall into that category for each payer in order to present useful data to patients. While most patients should know if they have a PPO or HMO or other type of plan, other groupings may not be so obvious. Asking patients to identify which group their plan belongs to before presenting them with data adds complexity to the user experience of the user likely to be least knowledgeable about how health insurance works. If asked to choose between more file complexity and additional duplication in files vs usability for patients the patients should win every time.

An alternative to a pre-defined set of allowed groups might be allowing hospitals to define their own groups but requiring them to provide a key to their group naming and a list of all plans included in each group might be a reasonable alternative. This would be more metadata to support in the CSV formats (if retained) and thus exacerbate the processing issues we discuss elsewhere in this document but would be easily supportable within a JSON framework.

We also note that this comment in the discussion of grouping of plans in the proposed rule is a bit confusing:

“because we propose to require hospitals to encode standard charge information in an MRF that conforms to a CMS template layout, the use of such template would ensure that the payer-specific negotiated charges remain `clearly associated' with the name of each payer and plan.”

It appears to indicate that the plan name will always be included in files that conform to the CMS templates, but the discussion just above indicates this is not going to be the case if the option to group plans is kept in the final rule.

Expected Allowed Amount

In general, our Data Governance Collaborative favors the idea of including an estimate expected allowed amount when a formula of some sort is used to calculate the actual charges so long as it’s clear how that estimate is determined. If the method described is already being used for revenue cycle activities, then using it seems to make sense.

Expected Allowed Amount and No Surprises Act

The discussion of standard charges in this document allows for the possibility of using a formula or algorithm to determine the actual amount owed for services and clearly indicates in several places that the exact amounts cannot be known until after the services are provided.

These same services, presumably, are covered by the No Surprises Act Good Faith Estimate requirements which do not make the same claims and require estimated specific dollar amounts for services ahead of those services being provided. Further, that estimate is binding in a way the data in an MRF is not. While more patient-specific information may make a better estimate possible, the contention here is that the specifics cannot be known until after the services are provided and presumably that is true no matter what type of estimate is being provided (otherwise the contention here would have been “without more specific patient data” or similar).

We ask CMS to clarify this apparent contradiction and, as appropriate, address it in this and future rulemaking related to price transparency in all of its incarnations including the hospital price transparency rules, the payer price transparency rules, and the No Surprises Act.

Charge Description and Inpatient/Outpatient Designation

We respectfully suggest that the charge description and the service setting (inpatient vs outpatient) are two distinct, potentially separately usable pieces of data and thus should not be combined into a single data element. Rather, there should be one data element for the service description and one to indicate whether the service was provided in an inpatient or outpatient setting.

Acknowledgement of Receipt of Warning Notice

The proposed requirement for acknowledging receipt of a warning letter from CMS indicates that the receiving entity must respond in form and manner and by the deadline indicated in the letter. While we believe reiterating the logistical specifics in the warning letter itself makes sense, we strongly believe a universal standard for the form, manner, and deadline for acknowledgement of receipt should be set as part of this rule. The form and manner requirement could specify using one of several options if CMS wants to allow multiple options.

Transparency of Enforcement Actions

Both MHDC and participants In our Data Governance Collaborative strongly believe in transparency when possible and laud CMS for its proposals to expand the public availability of enforcement actions. We agree with all of the proposed activity so long as there is a commitment to note when an entity fixes its issues and moves into compliance in a timely manner.

Response to Specific Questions – Price Transparency

This section will list specific questions asked in the price transparency section of the NPRM and provide our responses to them.

We therefore propose to…require that, in its MRF, each hospital add a statement affirming that, to the best of its knowledge and belief, the hospital has included all applicable standard charge information in its MRF…and that the information displayed is true, accurate, and complete as of the date indicated in the file. We seek comment on this proposal.

It is unclear to us that such an affirmation gains anything as mistakes and accidental omissions are just as likely to happen now as before. Unless CMS feels hospitals were being deliberately opaque or confusing, it does not seem like this approach is likely to result in fewer blank or empty data elements within an MRF.

Instead, we suggest an approach that CMS mentions some hospitals voluntarily implemented – using N/A or a similar affirmative notation for data that was deliberated omitted because it does not apply. Automated processing could handle either approach, but CMS indicated concern about human eyes trying to parse the data. For this constituency, use of N/A (or similar) is inherently easier to understand.

Further, since it requires an affirmative choice to populate, it is less likely to be used by accident than a blank field which still could be a deliberate choice or an accidental omission.

CMS could still require an affirmative statement that the data is complete and accurate, but this approach also makes it more human readable and slightly less likely to have accidental error in it as blank fields are automatically problematic and could be sought out, evaluated, and populated as part of a quality assurance process for the file.

We…propose to require hospitals to report this information [drug unit and type of measurement] as separate data elements. We seek comment on this proposal and the alternative we considered but are not proposing.

We strongly support requiring separate data elements for discrete, meaningful data values. As CMS notes, nothing prevents this information from also being included in the description.

That said, the specific data elements suggested here in conjunction with the example provided in the proposed rule confuse us. It seems like the key pieces to call out include the dose/strength per item, the units of measurement used for the dose, and the number of items (where the first two could be combined if desired). It is not at all clear how these map to the requested data elements; in the example it seems like the dose and units of measurement is being incorporated into the description and the number of items is being split into the two data elements being requested in a way that seems very artificial (perhaps there are better examples where that would not be the case). Regardless of the actual data elements required, we suggest adjusting the terminology used to be more explicit about the data expected in each element and to match more standard terminology usage (for example, units representing the unit of measurement and not the number of items). Perhaps additional examples that outline how the data elements work with different types of medications would be helpful as well.

We seek comment on this issue, and on whether we should instead require use of a single format (such as JSON).

Initially participants in our Data Governance Collaborative were split on the topic of file format and whether both CSV and JSON should be supported. Most agreed that supporting JSON was important, but a small but vocal group argued that supporting CSV was essential given its familiarity and current use.

However, as our conversation on other aspects of the proposed rule progressed, particularly around specific data and metadata requirements, it became more and more clear to all participants that JSON was much better suited to representing the rules as outlined. Even the most vocal CSV supporters had moved to the position of requiring the use of JSON by the end of our review of the proposed rule. Several specific points that prompted this realization include:

1. The requirement to include metadata within the MRF itself means that the CSV files would not be pure CSV files in the traditional sense of the word. In effect, the proposals are for text files containing both a bunch of random text (metadata) and a bunch of information formatted in a CSV style. This makes the files harder to parse and understand for both people and systems used to reading or interpreting CSV files (for example, most existing tooling for processing CSV or a similar character delimited file format expect the entire file to use it).
2. The requirement to include data from all contracted plans means that the number of columns in a wide format would likely be unmanageable; the number of rows related to the same item or service in the tall format would make it significantly harder for a human to identify the correct row of data if they tried to find it, negating part of the original familiarity argument.
3. The lack of hierarchical structure means choosing from two formats that require repetition of extensive amounts of data across rows and/or columns
4. The final nail in the coffin was the introduction of the idea of allowing additional optional data fields. While discussed as likely existing with a set column title in CSV and thus identifiable by programmatic means, the lack of standardization of the data contained within that field was deemed extremely problematic. Are key-value pairs going to be required to provide context and meaning for the extra data? How will the key and value be delimited? How will multiple key-value pairs be delimited? And so on. All of this is straightforward in JSON with its hierarchical structures and default use of key-value pairs.

We seek comment on whether hospitals would find a validator tool helpful and, if so, what technical specifications such a validator ought to assess.

We are in favor of providing a standard validator available to all hospitals; individual organizations should not have to build their own if a standard format is mandated for use by all.

At a minimum this validator should check:

• Whether the file is in the correct format (text file containing JSON or CSV + additional content)
• Whether the file is valid JSON or, if CSV is allowed, the portion of the file containing CSV data is valid CSV (same number of columns in every row, etc)
• Whether all of the required metadata is present
• Whether each required property/data value is present and meets stated requirements/constraints (minimum/maximum lengths, belongs to a specific value set/list of enumerated values, etc)
• Do the values make sense for the data elements they’re provided under (if possible)
• If extra optional values are supported, do they meet any stated requirements in terms of including context, key-value pairs, etc.

We seek comment on whether an indicator of non-applicability is necessary, whether such an indicator should be required or just recommended, and how CMS can best educate the public on the nature of standard charge information display, and, in particular, the potential for non-applicability in certain MRF formats.

We believe the correct answer to whether an N/A indicator is necessary depends on the format. N/A values are superfluous in JSON, but are more important in a CSV format where every row has to include the same number of values and there’s no way to determine if a blank value was intentional or not. We believe this added certainty that not providing data was a deliberate choice is helpful in CSV files and should be required, particularly given CMS comments around uncertainty in this area among existing users. However, there’s no reason why N/A values could not be specified in JSON (the only cost is slightly larger than necessary files) if CMS decides to support both formats and wants to have a consistent requirement across both. If JSON is the only format, we are inclined to using the standard JSON convention of omitting properties that do not apply, but would not oppose optional support for N/A in this case should there be widespread support for doing so. We do not believe N/A should be required if CMS decided to support only MRFs formatted in JSON.

As far as the educational component, we are not sure that it’s necessary. In theory, while individual people are free to read the machine readable files and some more technically minded individuals may choose to do so, their main purpose is for automation and any developers programming the ingestion and processing of JSON-formatted data should be familiar with the normal conventions and usage of JSON. A brief mention that you are using this standard convention in any documentation should be sufficient for that audience. The general public would, in theory, access this information only after it’s been filtered through some type of ingestion process and presented to them in a third party app or post-analysis website/white paper/etc. Educating them on JSON or CSV or the differences between the two seems counterproductive at best.

We seek comment on this proposed approach to improving accessibility of MRFs to automated searches.

We approve of both adding a text file with the specified information at the website root level and of including a footer with a link to the price transparency page to every public-facing page of the hospital website using the label outlined in the proposal.

We seek comment on this proposal, including on whether there are additional data sources that CMS could access for purposes of identifying health system affiliation and leadership contact information.

MHDC and our Data Governance Collaborative participants are strongly in favor of involving the health system in any non-compliance issues found at one of their hospitals and engaging them to ensure similar issues are not present elsewhere within the system.

Seeking Comment on Consumer-Friendly Displays and Alignment With Transparency in Coverage and No Surprises Act

Our Data Governance Collaborative had an extensive discussion about how the various price transparency laws and rules work in concert and what makes sense from both a patient and a payer/provider perspective. Some of this may not apply directly to the questions you ask (a few of which we will address specifically in sections below), but we felt it important to give CMS a sense of how a group of individuals who work in healthcare data and health IT at payers and providers feel about this both professionally and as patients.

Some of our key takeaways include:

• The most important thing for patients is knowing up front how much will insurance pay and how much they will have to pay for scheduled services. Patients don’t care about retail price or the contract details between a payer and provider, just what they’re going to owe for a service.
• If it’s not easy to find out what a medical procedure or visit will cost, some people likely won’t go unless it’s an emergency. Participants in our DGC have personally chosen to delay care because of a lack of information about how much it would cost.
• Healthcare is the only industry where consumers do not know how much something will cost them before deciding whether to buy it
• Both comparison shopping and not having surprise bills are important to patients. Personalized estimates are far superior to more generic options.
• Price transparency in general is difficult for the patient because there's so much involved. It's hard to make apples to apples comparisons. Providing information in ways that doesn't include enough context isn't helpful but sometimes the context makes it too complicated for the average patient.
• Patients are not using either payer or provider cost estimators in large numbers. One of our payer participants noted that this has been true for their cost estimator throughout its entire many years of existence. In response, another participant noted that they did not find the payer price estimation tools very accurate and thus gave up on using them long ago.
• The No Surprises Act estimates seem more consumer friendly and more accessible for patients than options available on payer or provider websites. The shopping scenario is challenging but it's important to try to do it for patients.
• One complicating factor around price estimation that gets little discussion is that the patient progress towards limits (deductibles, out-of-pocket maximums) can change in both directions. A claims re-submission can change the amount a patient owed for that service and put them below a threshold they had previously been told they’d met, meaning patients could be surprised they owe money when they thought they’d already surpassed the related threshold.
• Surprise bills can come in unexpected ways. For example, a patient can go to a primary care doctor for a supposed preventative care visit and mention they have some knee pain and the visit can then get reclassified out of the preventative care category and thus have additional unexpected charges associated with it.
• The length of time it takes to schedule with some providers exacerbates patient price concerns, especially if something unanticipated happens at the visit. For example, if you wait months to see a specialist for joint pain and they offer you a steroid injection on the spot that wasn’t pre-vetted ahead of time, it can be extremely difficult for the patient to decide if they should take the chance and get the injection without getting a price estimate first or do the proper research to determine if they can afford it which might mean waiting for months for another appointment later.
• Some things are likely impossible to accurately estimate, for example the cost of anesthesia for a procedure as that is usually based on a combination of the complexity of the patient and the amount of time anesthesia is needed.
• There is concern that requiring estimates be accurate within $400 means that estimates for larger or more expensive items and services will be estimated at their highest possible level to make them less likely to exceed the limit. Our participants strongly felt a percentage-based accuracy requirement was far superior to the $400 flat rate, particularly as that threshold is for each provider or facility involved in a service and not for the entire item or service combined. Further, patients are concerned about affording services that are likely to fall well under the $400 rate in total, and the current rules as written afford them little or no protection. Also, some form of protection for price increases on services estimated to cost $0 (such as the preventative services example above) are warranted.
• Offering an option to supply a range of costs, perhaps the 25^th percentile and 75^th percentile across a range of complexities or options is a way to address some of the more volatile pricing items and perhaps address any tendencies to provide the highest possible estimate for an item or service.
• One thing that can help with hospital price transparency is defining standard packages for common services for hospitals so that when comparing A vs A at two different hospitals A represents the same thing, particularly for high volume elective services. Maybe start with 10 and expand over time, using the same type of approach as CMS is using for Medicare drug price negotiations.
• In a fee-for-service market we don't know how individual providers will react to specific needs; bundles and or other types of value-based care would help enormously. Incorporating value based care into more care avenues will help make estimating things easier.
• There needs to be a holistic approach. The complexity of pricing for medical services is part of the issue. Lack of transparency of pricing is another, as is the lack of ability to connect pricing and quality information, and there are many other components. Addressing any one of these will help but not solve the problem.
• People talk about hospital price estimation tools as if they offer the equivalent information to No Surprises Act estimates for patients, but even if this were true we note that there are a lot of services that are not provided in a hospital setting and thus are not subject to hospital price transparency rules. These organizations are subject to No Surprises and do have to supply Good Faith Estimates.

How aware are consumers about healthcare pricing information available from hospitals? We solicit recommendations on raising consumer awareness.

There is some awareness, and things like the footer link added in this proposed rule will help. However, for the average patient, asking them to go to individual hospital websites to look up costs while already dealing with a medical need seems like a pretty high bar (especially if they’re trying to get estimates from multiple hospitals), and patients looking things up will always have a higher error rate in terms of finding the correct, applicable data than a professional sending them information specifically pertinent to them. These are some of the reasons our Data Governance Collaborative feels that No Surprises Act is far superior to the other price transparency options. Thus, we recommend devoting any spare resources to getting those processes fully up and running rather than trying to educate the public on the less ideal options available directly from hospital websites. If CMS decides to devote educational resources to this topic, some clear guidance on the differences between the different types of estimations and when/how each might be more appropriately used might be the best option (see below).

What elements of health pricing information do you think consumers find most valuable in advance of receiving care? How do consumers currently access this pricing information? What are consumers' preferences for accessing this price information?

Consumers want to know exactly how much a particular item or service will cost them directly before they commit to having the item or service performed. This is the single most important price transparency need for patients, one that participants in our DGC feel is best met via getting direct, personalized estimates per the No Surprises Act.

Given the new requirements and authorities through TIC final rules and the NSA, respectively, is there still benefit to requiring hospitals to display their standard charges in a “consumer-friendly” manner under the HPT regulations?

The general consensus of our Data Governance Collaborative is that the No Surprises Act estimates will better serve patients and that mechanism is preferred over both of the others. However, there are some benefits to having immediate access to perhaps less accurate data that can only be served via the hospital or (perhaps) payer price estimation tools.

Within the contours of the statutory authority conferred by section 2718(e) of the PHS Act, should information in the hospital consumer-friendly display (including the information displayed in online price estimator tools) be revised to enhance alignment with price information provided under the TIC final rules and NSA regulations? If so, which data should be revised and how?

We have no specific comments on what data should be revised, if any, but note that it can be confusing and/or problematic for patients if they access price estimations for the same items or services via different mechanisms and get different results. As long as these multiple mechanisms exist, some guidance on how to interpret them/why they might be different/which one is most trustworthy for various situations and why might be warranted.