Purpose
A fixed signpost for a file that moves
A hospital’s price file can live on its own site, a health system’s site, a storage service, or a vendor’s platform. The pointer file tells software which one the hospital says is the real file.
Before pointer files, finding a price file meant clicking through menus, scanning a price page, or guessing file names. That is hard to automate. It is also easy to grab the wrong thing, such as a patient estimator, an insurer’s file, or an old download.
The pointer file separates finding the file from storing it. The hospital keeps a small text file in a standard place on its website, while the big price file can sit somewhere else. If the price file moves, the hospital updates the pointer and software still knows where to start.
/cms-hpt.txt
A short text file that lists the location, the price page, the price file link and a contact.
A page for people
The public page where the hospital shows or links to its price file.
The full prices
The CSV or JSON download with all of the hospital’s standard prices.
Location
The path is simple on purpose
The website keeps the file in its top-level folder, so the address looks like https://hospital.example/cms-hpt.txt.
A top-level path works because anyone can check it without knowing how the site is organized. Other well-known text files on websites work the same way, but cms-hpt.txt has its own CMS-defined purpose and format.
The rule also requires a footer link labeled “Price Transparency.” It goes to the public page that hosts the price file link. The footer link helps people find the page. The pointer file gives software a direct route to the file.
Format
Five labeled lines make one entry
The rule asks for four pieces of information. The CMS text format splits the contact into a name line and an email line, so each location gets five lines.
location-name: Example Regional Hospital source-page-url: https://hospital.example/price-transparency mrf-url: https://files.example/123456789_example_standardcharges.csv contact-name: Price Transparency Team contact-email: [contact email]
The names and addresses above are made up. The line labels match the ones CMS pointer files use.
location-name- The hospital or campus these prices belong to. A specific name helps match a health-system pointer file to the right hospital.
source-page-url- The public web page where the hospital shows its price information and links to the price file.
mrf-url- A direct link to the CSV or JSON price file. It should open the file itself, not a general web page or a search tool.
contact-name- Who to ask about the price file. This can be a team or a job title instead of a person.
contact-email- An email address for that contact.
If one pointer file covers more than one location, a blank line separates the entries. The format is deliberately plain, so a browser, a command-line tool or a crawler can read it without running any scripts.
Hospitals and systems
One website can cover many locations
A health system can keep one pointer file with a separate entry for each hospital and campus on the same website.
Different locations can point to different price files. They can also point to the same file, if that file really covers them. The location name in each entry matters, because a system’s brand name alone may not tell you which hospital on the federal list it means.
The price file doesn’t have to live on the same website as the pointer file. A hospital may use a vendor or a file-hosting service for the large download. The pointer on the hospital’s or system’s own site is still what ties the location to that outside file.
Sharing a website is a useful clue about who owns what. It doesn’t prove that a file covers every hospital in the system. To be sure, you need the location entry and the hospital details inside the price file.
Common problems
A short file can still fail in several ways
The website works, but /cms-hpt.txt shows a “not found” page or something unrelated.
A security page, a site template or a redirect comes back where the pointer text should be.
A system pointer file opens, but no entry can be confidently matched to the hospital being checked.
The entry has no usable mrf-url, or it links to a web page instead of a direct CSV or JSON download.
The pointer file is there, but the price file it lists has moved, expired, or returns an error.
The server lets ordinary visitors in but rejects the automated request the tracker uses so that its checks can be repeated.
Names also vary. A pointer file might use a campus name, a legal name, a short brand or all capitals, while the hospital list uses something else. The tracker treats names as clues, but won’t force a match just because two hospitals share a website.
This tracker
The pointer file makes the check repeatable
The normal check goes from a known hospital website, to that hospital’s entry in the pointer file, to the price file the entry names.
Ask for /cms-hpt.txt on the hospital’s known public website and record the response.
Read the labeled lines and split out separate location entries.
Link an entry to a hospital only when the evidence supports it.
Ask for the price file link and read the start of the file, not the whole download.
Save what happened: whether the file opened, its template version, its update date, and the evidence someone needs to review the result.
If a site refuses the tracker’s automated request, the record says “Request denied.” That isn’t treated as proof the file is missing. If there is no usable website, or a system pointer file can’t be matched to a specific hospital, the record stays “Not assessed.” Keeping those apart shows where the check stops.
The project also keeps reviewed evidence from direct price file links when the standard pointer path isn’t available. That evidence is labeled by how it was obtained, and the file’s own header has to support the match to the hospital. A shared health-system source alone isn’t treated as proof.
Contact privacy
The evidence is kept without publishing searchable contacts
Pointer files are public, but their contact names and email addresses aren’t needed on the public tracker.
The project keeps the pointer text so results can be repeated and reviewed. Before it is stored, the values in contact-name and contact-email are scrambled. The key is included with the code, so this only stops casual plain-text searches. It is not encryption meant to keep the fields secret.
A maintainer running the local npm tools can unscramble the contact fields to review a source or prepare outreach. The public tracker data doesn’t include those fields, and the archived pointer folder isn’t part of the hosted site.
Sources