HPT Auditor: running the hospital price transparency checks before CMS does

HPT Auditor is a compliance tool I build and run for hospitals. Every hospital in the United States has to publish its prices under 45 CFR Part 180, and the Centers for Medicare & Medicaid Services (CMS) checks the work. HPT Auditor runs the same five checks CMS enforces, on a schedule, and hands back the evidence: what passed, what failed, when it was tested, and which paragraph of the regulation each finding is about.

Why build a price transparency auditor?

Because the penalties are priced by the day, and the failures are hard to see.

A hospital with 30 or fewer beds faces $300 a day. Above that, it's $10 per bed per day, capped at $5,500 a day. A 200-bed hospital is exposed to roughly $730,000 a year.

The money isn't the tricky part. The tricky part is that most failures are invisible from the inside. A footer link quietly changes. A machine-readable price file drifts out of the CMS schema. A required field goes missing on row 1,204. Nobody inside the hospital notices until a non-compliance letter arrives.

I came to this through client work. Another agency here in Mississippi contracts me to help build websites for rural hospitals and clinics, and once I learned the rules a Medicare or Medicaid provider has to follow, something struck me as odd. The best-known price transparency services were expensive, and many relied on consultants coming on site each quarter to audit. So I built a crawler that checks any hospital or clinic website against the federal requirements, as often as every day. A site that can break on any given day should be checked daily, not four times a year.

What does HPT Auditor check?

Each run tests five things, the same five CMS looks at:

1. The pricing link in the site footer.
2. The cms-hpt.txt locator file.
3. The price transparency page itself.
4. Whether the price file can be reached.
5. Whether the price file's format validates.

For the machine-readable files, I don't rely on my own reading of the schema. They're checked with the official CMS validator against the current data dictionary: validator v2.4.0 and data dictionary v3.0.0 as I write this.

Every finding is dated, names the paragraph of the regulation it tests, and comes with a cited action plan. A pass or fail on its own tells someone that something is wrong. A finding that points at the rule tells them what to fix and why, and gives them a record that they checked.

What about the rest of the rule?

The rule has a second half, and the platform covers that too. A Shoppable Services widget turns the hospital's price file into a price lookup that consumers can use, running on the hospital's own domain. There are also generators for the compliance pricing page and for the CMS locator file, so a failed check leads straight to the fix.

HPT Auditor is licensed per location, on annual agreements.

How do you test a tool that tests other people's websites?

You need websites to point it at. Mine are five mock hospital pages and a cms-hpt.txt file hosted on matchlessweb.com, hidden from search engines, which HPT Auditor's automated test plans load.

They live on a different domain from the product on purpose. The widget has to work when it's embedded on someone else's site, and a cross-origin test only means something if the test page really is on another origin.

I learned how easy those pages are to lose. When I rebuilt matchlessweb.com, the cutover dropped them, and they returned 404s for five days until I restored them with byte-identical content and a new stylesheet to match the new site. Now the site's post-deploy sweep checks that they're still there.

The lesson I took from that: test fixtures that live on another site are part of the product, even though no customer ever sees them. If a rebuild can delete them without anything failing, something should fail.

What am I still learning?

The reaction I hear most is surprise at the price. Administrators often assume a safety net like this costs tens of thousands of dollars a year, even for a single location.

The second surprise is where the prices live. The shoppable services list can sit on the hospital's own website, in its own branding, without changing any domain settings the way many third-party tools require. It reads as part of their site, not an add-on bolted onto it.

HPT Auditor does one job: it runs the checks CMS will run, before CMS runs them, and it shows its work. If you're responsible for a hospital's website, the five checks above are a good place to start even without a tool. If you'd rather have them run on a schedule, it's at hptauditor.com.

Stack: the official CMS validator (v2.4.0) and data dictionary (v3.0.0), TestSprite test plans, and mock hospital test pages on matchlessweb.com (Cloudflare Pages). The app itself: React 19 and Vite on the front end, a Python (FastAPI) service with Playwright running the checks, Supabase for the database and sign-in, Cloudflare Pages, a Worker and R2 for hosting and the embeddable widget, and Stripe for billing.