Privacy Policy

Analytics & advertising

Some of our information pages (such as About, the blog, the guides, the tour and What’s new) use the image form of the LinkedIn Insight Tag, a service provided by LinkedIn: once the page has loaded, it requests a one-pixel image from px.ads.linkedin.com to count visits and to let us show relevant ads to visitors on LinkedIn (retargeting). No LinkedIn script runs on any of our pages. The pricing tools, sign-in, this policy, the terms, the API and the integrations pages do not request it at all, and no page requests it when its address carries inputs (anything after a “?” or “#”). With the image request LinkedIn receives your IP address, browser information, the time and our site’s address (not the page you are on), and it may read or set its own cookies in your browser. We use it only in aggregate to understand interest in the product; we do not use it to identify individual visitors.

Technical & security data

Like any website, our servers and our content-delivery/security provider (Cloudflare) process standard request data — including your IP address and browser user-agent — to deliver pages, prevent abuse, and enforce rate limits. This is used for operating and securing the service.

Information you submit

• Contact / access requests: if you email us or submit a form, we receive the email address and message you provide, and use them only to respond.
• Signing in: signing in is optional: pricing and every download work without it. If you sign in with your email, we use the address to email you a one-time sign-in code through Amazon Web Services (Amazon SES) and to apply your limits while you are signed in. When the sign-in form shows a Cloudflare Turnstile check, Cloudflare receives your browser and network details for that check, to tell people from automated requests. We keep only a scrambled copy of the code, for up to 10 minutes, and do not use the address for marketing. If your organization signs its people in through its own sign-in service (single sign-on), you sign in on your organization's page, not ours: we receive from it only your email address and confirmation that it signed you in, and no code is emailed. Accounts we set up for you use a user ID and a password we store only as a one-way hash. Your session stays in that browser tab and ends when it expires, you sign out, or you close the tab. We keep a record of each sign-in (the email address or user ID, the time, your IP address and browser) and of user IDs locked after repeated wrong tries, in a private Amazon S3 store, to see who uses the service and to spot misuse. Each entry is deleted automatically one year after it is made. A user ID that matches no account is never kept as typed, only as a scrambled tag. While you are signed in we count your requests per day to apply your daily limit. We review each new email sign-in by hand before lifting the free-tier limits; for that review we keep the address, its domain, the network it signed in from and how many claims that network priced that day, in the same private store.
• Calculator inputs: values you enter (such as codes, hospital, or claim fields) are processed to generate a result. They are not tied to your identity and are not used for advertising. A claim’s charges and other amounts, dates of service, days, units, ages and discharge status are never written into the page address. The address, links between pages and links you copy can carry codes (an MS-DRG, diagnosis, procedure or fee code), a hospital’s CCN or a provider’s NPI, and settings such as the state or the service ZIP, so the page opens on the same case; none of them carries a patient identifier.
• Claim and remittance files (837, 835, FHIR, JSON, XML, UB-04 PDF): please use de-identified or test files where you can. On the claim import page, before a text file (837, 835, FHIR, JSON or XML) leaves your browser, the page removes patient and subscriber names, member and subscriber IDs, Social Security numbers, addresses, phone numbers and email addresses, medical record and policy numbers, free-text notes and dates of death. A date of birth is replaced by the patient’s age at the date of service (ages over 89 are sent as 90). Claim and payer claim numbers are replaced with tokens; the page keeps the link between a token and your number in its own memory, only to show you your own numbers in the result, and forgets it when you close the page. The page shows, for each file, what kinds of identifiers it removed. Our server then applies the same rules again before reading the file, so a file sent to the API directly is treated the same way, apart from the tokens: an API caller’s claim numbers are kept and returned so the result can be matched to the claim. What is read is what pricing needs: diagnosis and procedure codes, POA indicators, dates of service, charges and service lines, bill type, discharge status, the patient’s age and sex, the billing provider’s NPI and CCN, and the DRG and amounts on a claim or remittance. The file is parsed in memory and not stored. A UB-04 PDF cannot be cleaned in the browser: it is sent as is, the server reads only diagnosis, procedure, status and DRG code shapes from its text and returns none of the text. The removal is automatic and works on the standard places these formats keep identifiers; an identifier typed into an unexpected field may not be caught, which is why de-identified or test files are still the safer choice. Inpatient (IPPS DRG) reads an 837 in your browser instead, and sends the server only the codes, dates, charges, age and sex it needs.
• What is never logged: request bodies (claim files, claim fields, uploaded tables) are not written to our logs. Every pricing page, the Classic pricer included, sends the claim it prices (charges, dates, codes and hospital) in the request body, not in the web address; a look-up of one code, hospital or NPI puts only what you looked up in the address. For each request, our server logs record the time, the method and route requested, the response status and your IP address. The route is logged without the values in it: nothing after a “?” is kept, and a code or CCN in the path is logged by its name (a hospital look-up is logged as /drg/hospitals/{ccn}). When a request fails on our server, the log records where in our code it failed, never the values it was handling. Error replies go only to you and are not logged; one that refuses a malformed field names the field without quoting it. Repriced 837 and 835 files and CSVs are built in your browser. Medicare worksheets (PDF and Excel) and the batch Excel workbook are built on our server from the priced result, which carries no patient identifiers, and are returned, not kept.
• Optional AI features: when you click an AI feature (such as Ask AI on a clinical note, claim assist, or Explain this payment), the text or claim it works on is sent through our server to our AI model provider, Anthropic, for that one request. We do not store it. AI features never run unless you click them; leave names, dates of birth, member IDs and other patient identifiers out of anything you send.
• Provider screening: the provider NPIs on a claim you price or import (and, for one claim at a time, the provider's name and state) are compared with public lists, today the OIG List of Excluded Individuals/Entities, on our server, for that one request. The list is a public federal download kept on the server; nothing is looked up with a third party. We do not store or log the providers you send or what the check finds. A result is not a payment determination.

Third-party services

We rely on a small number of providers to run the site: Cloudflare (content delivery and security), Render (hosting), Amazon Web Services (sign-in code emails and the sign-in record, only if you sign in), Web3Forms (delivers the contact, access-request and free-review forms to our inbox), LinkedIn (visit counts and advertising on some information pages, described above), and Anthropic (AI model provider, only for the optional AI features above). Each processes data under its own privacy policy.

Your choices

• Opt out of LinkedIn advertising via the link above.
• Block or delete cookies in your browser.
• If your browser sends a Global Privacy Control or Do Not Track signal, our pages do not request the LinkedIn image at all.

Contact

Questions about this policy? Email info@payerparity.com.