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
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).
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:
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
This section will list specific questions asked in the price transparency section of the NPRM and provide our responses to them.
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 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.
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:
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:
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 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.
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.
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:
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).
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.
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.
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.