How it works, briefly

Pre-Price answers what an operation will cost before you have it, using the hospital's own published price file rather than an estimate.

The rule it is built around: the model is not allowed to do arithmetic. It cites the row and column for every figure, and code checks each number against the cell it claims to come from. Anything that does not match is deleted before you see it.

The quote itself becomes a real PayPal invoice, or a subscription if the patient needs instalments.


Hospitals publish their prices. Nobody can read them.

Since 2021, US hospitals have been required to publish a machine-readable file of every price they charge, for every payer. The compliance box is ticked. The files exist.

They are also 84MB zip archives containing hundreds of thousands of rows keyed by billing code, with payer-specific negotiated rates in columns nobody outside revenue-cycle management can name. One of the files this app reads is 14MB of CSV. Another is 84MB compressed.

So the price of your knee operation is public, and you cannot find it.

Ask any hospital what a procedure costs and you get a range, a disclaimer, and a suggestion to call billing after the fact. The information asymmetry that the rule was written to fix is intact, because publishing is not the same as answering.


The problem with pointing a language model at it

The obvious move is to let a model read the file and tell you the number. The obvious move is also how you get a confidently wrong price for surgery.

We saw it happen. On one run the model added two rows together and produced a total that appears nowhere in any file. It was plausible, well-formatted, and invented.

Ask in plain words

So Pre-Price is built around a rule that sounds severe and is the entire point:

The model is not allowed to do arithmetic. It must cite the row and column for every figure. Code then checks each number against the cell it claims to come from and deletes any that does not match.

The model's job is to find the right rows. Finding is what it is good at — matching "a torn meniscus in my knee, keyhole surgery" to the billing code a hospital files it under is genuinely hard, and it does it well. Adding two numbers is what code is good at. We do not let them swap.

When the invented total appeared, the check caught it and removed it before anyone saw a quote.


What you get

A quote, traced

A plain-English description goes in. What comes back is a figure with the cell behind it.

The files themselves

The files are real. Johns Hopkins, Brookings, McLaren Flint, Wentworth — streamed and parsed rather than summarised in advance, because a summary is where the traceability dies.

The evidence

Every number links to its source row. If a figure cannot be cited, it does not appear.


Then the money

A quote is not much use if paying it means another phone call. So the quote is a PayPal object.

  • A real PayPal invoice, built from a template, with itemised lines, partial payment allowed, a QR code and scheduled reminders
  • Or a real PayPal subscription on a real billing plan, if the patient needs instalments
  • Idempotent on a deterministic invoice_number, because Invoicing v2 ignores PayPal-Request-Id on create — which surprised us, since Payouts honours sender_batch_id exactly as documented

The app holds 60 PayPal object IDs and 28 real invoices.


How it works

Where PayPal's sandbox stops

The sandbox has no clock control for subscriptions, so a renewal cannot be fast-forwarded. The "record the next payment" button stands in for a billing cycle and is labelled wherever it appears. Invoices and subscriptions themselves are real.


Built With

Share this project:

Updates

Submission history