Commenting on Hospitals Public List of Standard Charges

This is my final post in the series covering the Hospital Price Transparency Executive Order.

CMS recently proposed guidelines for how hospitals should list their standard charges to the public, as required by the Executive Order. I submitted comments to CMS on this portion of the proposed rule because of its great significance to patients, and I am sharing them below (with minor edits).

The previous post in this series is Establishing a Health Quality Roadmap.

General comments

We applaud that CMS, as a fundamental stakeholder, is considering tool-builders. CMS is correct in its assertion that tools to convert machine-readable and complex data released by inpatient hospitals will be required in order for patients/consumers to have a good price-shopping experience. While many Americans have become used to comparing prices on menus at restaurants, pricing for hospital services is complex, varied, and depends on comorbidity rates. Tools will be required to accomplish these ends and CMS is correct to consider them. CMS should weigh comments from ourselves and other organizations with a history of tool-building more heavily, regarding the specific details of file structures and machine-readable details.

Inauguración del Hospital Municipal de Chiconcuac

Photo credit – Flickr: Presidencia de la República Mexicana

Regarding the definition of hospital:

For the purposes of this proposed rule, the definition of “hospital” should be extended to include Ambulatory Surgery Centers or any facility that conducts surgery with anesthesia. It is not fair marketplace transparency if it is the privilege of a portion of the marketplace to hide prices.

Doing otherwise will incentivize inpatient facilities to “spin out” all of their surgeries to newly formed ASC facilities to continue the practice of hiding prices and using this as a negotiating tactic against patients/consumers. This is a loophole that should be fixed.

CMS is correct in not allowing rural hospitals or critical access hospitals (CAHs) to be released from the pricing transparency requirements. However, no hospital should be exempted from releasing data because they provide a pricing tool. While some pricing tools offered by hospitals can be excellent, pricing tools can also serve to mislead patients/consumers using dark UX patterns. These dark UX patterns are too complex for CMS to regulate against. Instead, the requirement for machine-readable consistent price information must be universal.

Please also see our notes on the concepts of “items and services”, and how those change how a “hospital” should be defined.

Regarding the definition of “items and services”:

HCPCS and CPT codes, as well as ICD procedure codes (different than the more commonly referenced ICD diagnosis codes), must be added to the list of items and services that include machine-readable price information. If this is not done, then inpatient facilities will find ways to extend charges to cash-pay patients/consumers that includes services codified under these mechanisms to inflate final charges. This is another case where hospitals will react to incentives by simply reconfiguring their services in order to avoid comparable market pricing.

For example, a patient/consumer might find that hospital A charges $3,000 for DRG ABC123. While hospital B charges $5,000. But then they find when they receive a bill for services at hospital A, that DRG ABC123 is always accompanied by HCPCS XXXX or ICD procedure code YYYY which also costs $3,000. Making the total charges to the patients/consumers $6,000. CMS policy must ensure that these kinds of ‘hidden’ fees do not occur merely because of limited billing vocabulary requirements in pricing systems.

This will also benefit subsequent transparency efforts in the outpatient environment.

CMS must also ensure that all services, even those provided by non-hospital-employed providers be included in price transparency. The notion that there can be “services provided at the hospital and inside the hospital”, which do not count as services provided “by” the hospital, is semantic dithering. Especially considering that without those, general hospital services would be impossible.

The only reason why a “hospital” should be thought of as a legal entity that can have critical services provided “inside” it but not “by” it, is because CMS allowed for that notion as it defined hospitals. It is clear that for a marketplace to exist, the definition of “hospital” must be brought in line with patient/consumer understanding, which does not include any notion of dual-source billing.

These kinds of confusing arrangements are found nowhere else in consumer commerce. There are certainly partnerships in the services that consumers receive, but never a partnership that refuses to reveal clear prices upfront. Purchasing a phone from Apple and phone service from Verizon, for instance, does not mean that a consumer means to guess about their service or phone price. Neither does buying automobiles from Ford and gasoline from Shell. The notion that a partnership, of any kind, should be able to obscure merged prices is incompatible with any notion of a fair market. Either CMS will put hospitals in a position to be fully responsible for transparency around the entire bill that patients/consumers receive, or it can look forward to hospitals moving capital and services into the “partnerships” in order to take advantage of the hidden pricing that such a partnership would enable.

After all, if 10% of the services of a hospital can be delivered by partners who intentionally obscure prices in order to facilitate additional charges to the patients/consumers involved, why not simply have the same arrangement for 95% of the services that a hospital offers? If “non-employed” service providers are exempt from transparency, then entire hospitals will move their resources into a “non-employed” business model.

The solution is simple: Hospitals should be responsible to publish all prices and contracts that they offer directly or that are offered through them. This rule will allow patients/consumers to look at the hospital pricing in the same way they look at the hospital itself, as a single unit delivering competitive care with other comparable hospitals.

Note that our ongoing standards efforts at https://github.com/docgraph/Hospital_Charge_Master_Data_Schema intend to account for these types of pass-through data forwarding arrangements.

Decile range of business percentage:

Frequently, hospitals give deep discounts to payers who send a greater percentage of patients to a hospital. They also, however, give steep discounts to payers over retail prices, even when a payer does not send many patients to a given hospital.

We propose that CMS require hospital plans to also publish the decile-range of the percentage of patients that the hospital sees under a given contract. For instance:

Aetna: 40-50%

Cigna: 0-10%

BCBS: 10-20%

Medicare: 30-40%

Etc.

If a provider’s retail cash-pay rate for procedure ABC123 is $5,500 and there are three “0-10%” commercial payers who all pay $3,400, then this is a signal to cash-pay patients that the cash-pay rate is unreasonable. This will give them the opportunity to negotiate with the hospital or choose to shop at a hospital whose rates for cash-pay or high-deductible patients are in line with rates charged to low-volume payers.

Conversely, publishing this data would also give hospitals room to justify higher discounts to payers that provide a greater volume of patients to the hospital.

Missing “Consensus-Based Data Standards”

Executive Order on Improving Price and Quality Transparency in American Healthcare to Put Patients First requires that CMS use “consensus-based data standards” for its machine-readable files. Every mention of the term “machine-readable” in section XVI should be replaced with “machine-readable consensus-based data standards”. It is completely inappropriate that this part of the Executive Order has been ignored.

Even if CMS were not ignoring specific language from the Executive Order eliminating this requirement will not be effective. Any implicit inline “data element” definition that is included in the regulation will be simply too brittle to be considered a “consensus-based data standard”.

The current document proposes data elements with such specificity that it seems HHS/CMS might have imagined that the regulatory process itself might be a stand-in for “consensus-based data standard”. But the whole point of “consensus-based data standards” is that they can be changed quickly when they need to be, and can be responsive to the industry in precisely the way that regulation cannot.

There are two meaningful efforts that might count as “consensus-based data standards” for machine-readable files for hospital pricing data. One is our effort that is hosted at:

https://hospitalpricedata.org/

With a consensus process run by Github issues and pull requests.

Our particular standard is defined here:

https://github.com/docgraph/Hospital_Charge_Master_Data_Schema

The other potential platform is the FHIR platform, which (as far as we know) does not yet have a bulk-data pricing endpoint specification, but could easily have one added without much trouble.

The marketplace should decide which consensus-based data standard to settle on for this machine-readable file format, but CMS/HHS must require (according to the Executive Order) that some consensus-based mechanism is chosen.

Once this regulation is released into a final rule, we will be looping in collaborating parties (including both data journalists and representatives from the hospital industry) to ensure that this standard incorporates the specific requirements outlined in your regulation.

This will include all of the fields that you end up requiring. And frankly, it will eventually include all of the fields that CMS should have required, but was not able to magically know in advance. The standard will grow to address all of the following issues:

How to express partnership-based pass-through pricing
How to express the variations of different cost estimation methods
How to properly identify the various insurance carriers
Where the data files should typically be hosted on a website
Mechanisms for converting data into patient/consumer-friendly human-readable PDFs, etc

Our data standard and any FHIR effort (which would inevitably start by forking or reacting to our more mature effort) have already thought through and solved dozens of complex issues that CMS has not yet considered. Assuming the regulations released after these comments are processed are sensible, there are likely to be dozens of features that we will need to implement that CMS had thought of, but that we had not. That is exactly the benefit of the consensus-based approach that the Executive Order clearly mandated.

Likely, the folks running FHIR will look at our effort and choose not to implement a profile, or they will implement a good profile and we will abandon our efforts. It is entirely possible that our effort will simply become the FHIR profile. There is a small chance that the standards would actually compete, but this is fairly improbable.

Whichever path is taken in our consensus process, having all of the hospitals use the same or very similar data standards is hugely important to the success of this program. Otherwise, tool builders will need to write custom parsers for each hospital’s data files. In the event that our standard and FHIR do end up being competing standards, tool builders would still only need to build two simple data parsers, as different hospitals choose one consensus-based data standard over another.

Centralized hosting of the list of machine-readable websites

This is the approach that was taken with the hosting of the JSON metafiles for provider networks and formularies on the health insurance exchange which worked pretty well.

More importantly, CMS will have to maintain and acquire such a list or many such lists in order to perform any kind of reasonable monitoring process. Once that happens, the lists will become FOIA available. This will mean that CMS will inevitably be required to compile a list of such endpoints from a FOIA request from us and likely dozens of others.

It was this “FOIA inevitability” that caused the HHS/CMS NPPES project to decide to proactively share the contents of the NPPES database on a regular basis as a PUF. Please carefully read the FOIA disclosure policies released by that project, the underlying reasoning will eventually apply to the lists of machine-readable endpoints.

So the issue is not whether HHS/CMS will host a centralized resource for making this data available, it is whether this centralized resource will be well-designed and simple to use for all involved.

In reality, CMS should simply add an additional field for this URL to NPPES (which now has a space for it in the endpoints file) and require that the location of this pricing URL be an “endpoint” under the NPPES system.

This will require convincing the somewhat reluctant CMS NPPES team to instruct the frequently obstinant contractor that runs NPPES to implement this requirement.

The alternative, however, is to develop exactly the same functionality but to search through dozens of CMS employee email accounts for URLs in response to a FOIA request. This is what would happen if CMS has no centralized requirement to host this data.

Alternatively, CMS could develop a new system, with the following features:

A system to track provider login mechanisms
A system to allow providers to upload data
A system to ensure that the uploaded data is at least syntactically valid (i.e. it is a URL)
A mechanism to disseminate this information on a regular basis.

NPPES already does all of these things, which is why it makes sense to not re-implement all of these systems.

This also serves to address the complicated problem of “site” based pricing URLs. CMS and other payers already require that different hospital sites acquire different NPI records. And these different records could reference different pricing URLs. Perfectly resolving, the otherwise intractable, multiple hospital site problem. As a side-effect of this, some hospitals might need to acquire new NPI numbers for sites with different price sheets, but this is precisely the correct outcome.

The basic principle here is that different prices mandate different NPI numbers and deserve to be thought of as distinct hospitals. Again, the notion that “one hospital” can have two different price sheets, but from an NPI standpoint is a single entity, violates any kind of reasonable understanding of how much cognitive dissonance the average patient/consumer can understand.

Having a centralized list would enable CMS to hire MITRE or NIST or someone else to write code to ensure that the data that was being released was actually:

Machine-readable
Conformant to relevant data standards
Contained syntactically valid procedure/drug codes

With a trivial amount of effort to implement programmatically, this puts CMS in a good position to consider compliance with other, higher level, pricing considerations. But without this layer to ensure data parsability, other monitoring tasks are going to be impossible to consider with any kind of facility.

Want to think about whether the right classes of prices are being released? Impossible without reliable parsing. Want to think about whether hospitals are releasing all of the prices for procedures that they actually perform? Impossible without reliable parsing. Want to know if the shoppable menu items that CMS is considering prioritizing are being honored? Impossible without reliable parsing. Want to know if things are changing over time, and new procedures are being included in price lists? Impossible without reliable parsing. Want to understand the relationship between the cost report data that CMS already collects and the open pricing information? Impossible without reliable parsing.

There is literally no monitoring exercise that we can imagine the HHS/CDC/ONC/NIH/CMS/et al would want to undertake that is possible without having reliable parsing that can be checked across all hospitals in the country.

Based on this regulation, CMS clearly harbors the idea that the marketplace could handle this function. This is not a realistic expectation. It is certainly true that if CMS set up this kind of automated monitoring, private industry could easily emulate the effort. But without CMS taking responsibility for this central data capture function, no marketplace based effort could really succeed. This is not a hypothetical, we are involved in ongoing effort to simply catalog hospital URLs for current pricing information. When we cannot find it, we are forced to have an interchange that boils down to ‘Fred Trotter assuring some hospital CIO that Seema Verma would be upset if the url access was not made more reasonable’. And subsequently forwarding the relevant tweet from Seema Verma as evidence of this claim.

Outside marketplace data aggregators are not going to be able to meaningfully enforce:

That real machine-readable standard be used
Actual compliance with the details of the XML/CSV/JSON standards
Compliance with any higher level consensus-based data standard

Why would the HHS/CMS bet on XML?

We are not sure who advised someone at HHS/CMS that it was reasonable to assert that anything is done: “using a single standardized file format, specifically.XML only, because this format is generally easily downloadable and readable for many health care consumers,”

XML is not readable by consumers. There are dozens of entirely valid variations of XML machine-readable. For instance, the person who gave this (bad) advice was probably thinking of something that looked like this:

<?xml version=”1.0″ encoding=”UTF-8″?>

<note>

<heading>Reminder</heading>

<body>Don’t forget me this weekend!</body>

</note>

Which is a lovely example that can be seen by right-clicking and choosing “view source” here:

https://www.w3schools.com/xml/note.xml

And indeed, this could be considered human readable. Sadly, this is not representative of real world XML. Real world XML looks like this:

<?xml version=”1.0″ encoding=”UTF-8″?><?xml-stylesheet href=”https://www.accessdata.fda.gov/spl/stylesheet/spl.xsl” type=”text/xsl”?>

<title>Prozac (Fluoxetine hydrochloride) capsule </title>

<time/>

</assignedEntity>

</representedOrganization>

</assignedEntity>

</author>

<name>Prozac<suffix/>

</name>

<name>Fluoxetine hydrochloride</name>

</genericMedicine>

</asEntityWithGeneric>

</definingMaterialKind>

</asEquivalentEntity>

</quantity>

<name>Fluoxetine hydrochloride</name>

<name>Fluoxetine </name>

</activeMoiety>

</ingredientSubstance>

</ingredient>

</numerator>

</quantity>

</containerPackagedProduct>

</asContent>

</manufacturedProduct>

</effectiveTime>

</marketingAct>

</subjectOf>

</territory>

</territorialAuthority>

</author>

</approval>

</subjectOf>

Please take a moment to admit, in your heart of hearts, that after a few moments you just skipped over the above text and did not even attempt to read it.

This BTW is actually XML that is released by the FDA. It is horrifically hard to parse and almost all standard programming language XML libraries cannot handle it. It will literally crash. This is so difficult, in fact, that the python code used in open.fda.gov to parse these files literally just deletes a part of the XML file, because it is unparseable by python libraries.

And yet (and this is critical) the FDA SPL XML files are 100% correctly formatted XML files. These are the types of problems that caused the programmer community to move away from XML, and XML files produced by the FDA cannot be parsed by software written by the FDA.

While it is certainly possible to have human-reading-friendly XML, there is nothing inherent with XML that makes it readable. The notion that you would have settled on this, instead of JSON, as the candidate for “a single machine and human-readable format” is based on some very bad advice. An entire industry’s interest in the underlying data standard.

Below you will see the Google Trend comparison between JSON and XML. This shows the level of search interest in the technologies over time.

Here is the corresponding graph for the technology popularity on Stack Overflow, which is generally regarded as the most popular resource for programmer Q/A topics.

In both systems, JSON is clearly overtaking XML in popularity. One of the reasons for this shift in interest is that while JSON and “readable” XML are approximate as readable, “unreadable” XML is really difficult to work with. There is nothing in the current proposal, and there is nothing that we might imagine could be added to a proposal like this, which would result in hospitals avoiding generating silly and crufty XML data files.

Also, note that neither FHIR nor our own hospital price standard (the only two that qualify as “consensus-based data standards” under the Executive Order) considers XML as a possible file format.

In fact, the entire massive move from previous HL7 standards to the now mandated FHIR based interoperability approach represents a move away from XML and towards JSON. This is true for the Direct Project as well. CMS’ own programs are already moving XML to JSON.

Honoring prices

Probably the most significant issue that is not explicitly covered in the open pricing information regulations is the means to detect hospitals that simply do not honor the inherent obligation to keep their published prices in line with those they actually bill patients with.

A new type of fraud, that CMS will need to account for in the long term, will be hospitals that create “shadow charge-masters”, where they publish one set of prices in a machine-readable format, but then use a different pricing scheme as they bill out-of-pocket patients or out-of-network health insurance providers.

We applaud the movement towards open price information for hospitals, but it should be explicit that charging different prices than those advertised is fraudulent and will be treated as such.

CMS should create a monitoring system for “price surprise”

CMS should create a website for consumers to report cases where the price for services was much different than they were expecting, despite having used pricing tools powered by open pricing data.

The website should request a few things:

A screenshot or email receipt from the prices estimation tool
The URL of the price estimation tool
A copy of the hospital bill that was surprising
A URL of the hospital that provided the bill
The first day of the hospital stay in question

CMS should invest in technology to immediately de-identify this data and separate the identity from the complaint. This will be non-trivial because the name of the person is likely in dozens of places including images. However, once this deidentification has been completed and verified, this should be released as part of a public dataset. In order to ensure the privacy of reporting parties, the published data should be limited to:

The name of hospital
The URL of the hospital
The total amount of the bill
The name of the price estimation tool
The URL of the price estimation tool
The amount that the tool estimated the price to be
The year and quarter the treatment occurred

It would be better if there was a way to transmit the underlying DRG/HCPCS codes along with this information, but it adds complexity to the deidentification and complaint process. As a result, this feature should be postponed.

Over time, this “price surprise complaint” open data resource will reveal which price estimation tools are frequently wrong, and which hospitals frequently violate open price data commitments.

Regarding the rate of release of data:

Instead of releasing the file weekly or monthly or quarterly, what we really want to avoid is “the prices have changed since then” arguments. Instead, hospitals should be required to provide the date of release in the file names and should be prevented from changing prices more than 5% between any previously published price rate and actual billed rate. Specifically, the download file should take the form of:

MethodistHospitalPrices.2020.08.31.csv

Or

MethodistHospitalPrices.2020.08.31.json

Such that the file, when listed with previous versions of the file, will be sortable by date in directory listings.

So if the file indicates that DRC ABC123 costs $2,200 with no insurance plan, and if they want to change the price by more than 5%, they have to release a new file, with a new date. So if a patient receives a procedure for ABC123 and is charged $5,000, and the most recent version of the file said $2,200, then the maximum that the patient will actually have to pay would be $2,310 based on a 5% increase on $2,200.

This makes a change in prices the reason to update the file, which is the same reason frequent updates are necessary. In fact, the rule should explicitly state that hospitals should be able to change their published prices no more frequently than once per month.

Fred Trotter

Fred shapes our software development and data gathering strategies, which doesn't stop him from getting elbow-deep in the code on a regular basis. He is co-author of the first Health IT O’Reilly book Hacking Healthcare, and co-creator of the DIRECT protocol mandated in Meaningful Use. Fred’s technical commentary and data journalism work has been featured in several online and print journals including Wired, Forbes, U.S. News, NPR, Government Health IT, and Modern Healthcare.