What Payerworks holds, for whom, and for how long.

The Site has one form for reaching us. When you use it we collect what you type: your name, your work email, the name of your organization, the kind of organization it is, and what you want to connect. We use that to reply to you and for nothing else. When you send it, an automatic email confirms we received it; then a person replies by email. There is no follow-up sequence, no phone call, and the Site never asks for a phone number.

The Developers page has a second form, for a test key to the Payerworks API. It asks for your name, your work email, the name of your organization and your word that you will send invented test data only. We email a link to that address, keep the request for a day or until the link is used, and keep the address beside the key we issue, so that one address holds one test key and so that we can write to you about that key; it is also that key’s first notice address (below), which you may change or remove. We count how many links are asked for, by address and by network, to stop abuse.

The console works with a key you paste into the page. The key stays in your browser while the page is open, is sent only to the Payerworks API, and is never stored by the Site. If you set a webhook, we keep its address and its signing secret until you remove it, so that we can sign and send your events; when you ask for a new secret, the one before it keeps signing beside it for the overlap you ask, from none to 720 hours (24 if you ask none), so that your server can switch over, and is deleted at the next change to the webhook after that. If you add webhook destinations, we keep each one’s name, address, event types, settings and signing secret (and the secret before it, the same way) until you remove it, with when it started failing and when we emailed about it; and for each event sent to one, its delivery and every attempt, with the status your server answered or why the attempt failed, in our own words and never what your server sent back, for as long as the event is kept. We keep your key’s notice address, the address your test key’s link was sent to (the only one it may be set to), until you remove it, and we email it when a destination keeps failing and when your enrollment requests move without your doing it; each move for that email is kept for 7 days after it was written, sent or not, and names only the request’s id, the provider’s name and NPI, the payer, the transaction and the status. If you make or rotate keys through the API, we keep each key’s name, mode, last four characters and account, and when it was made, expires, was rotated and was revoked, also after it is revoked, and never the key itself, only a one-way hash of it; a rotated key’s old secret is accepted for the overlap you ask, from none to 720 hours (24 if you ask none). For every key we keep a count of its calls by day and of the calls refused before they ran, and for each account a count by day of its keys’ reads on each route that reads a picture with a model and of the events they recorded, and never what a call sent. We keep each event queued for your webhook for 30 days, holding the sandbox’s invented answer and, from what you sent, only your claim references and your file’s control numbers, or for an enrollment event only its ids, statuses and words. If you use the enrollment routes, we keep the providers and enrollment requests you create (names, NPIs, tax ids, contacts and notes) and the PDFs you upload for a task, because a request lives for weeks and our people work it: a test key’s providers and requests expire 30 days after their last change, and its PDFs 30 days after each was uploaded, or about a day after you delete one, and a PDF uploaded but never confirmed goes after a day; a live key’s are kept until you delete them, and the copy of a deleted live PDF for 30 days more. Apart from that, our backups hold every PDF that was there each night, a test key’s included, for 35 days, and each Sunday’s for a year. They are for a practice’s business facts, never a patient’s information. For 24 hours we keep a fingerprint of each request sent with an Idempotency-Key, so that a retry is answered the same way, and never the request itself. If you use the API’s SFTP file drop, we keep its user (its name, your acknowledgment setting and each SSH public key you add, without its comment) until you remove it or its key is revoked or expires: it is removed at once when the key is revoked, and by our daily pass within a day of the key’s expiry or of a revoke at which it could not be removed. A file you drop is read once and deleted as soon as its answers are written, or one day after it arrived if the drop never reached it; each answer waits in your folder for 7 days and is then deleted (the storage service removes an expired file in the day or so after its expiry); the drop keeps no earlier version of a file and is in no backup; and the endpoint’s transfer log records the name of each file moved, so never put an identifier in a file name. If you use the API’s batch jobs, we keep the file you upload for a job until the job finishes, when it is deleted, or one day after it arrived if the job never ran; we keep the job’s result for 24 hours after the job finishes, and only within those hours do we give out a link to it; we keep the job’s record (the route, its state, its counts, the result’s size and fingerprint, never a byte of the file or the result) until an hour after those hours are over, and the table removes it in the day or so after. The storage service removes an expired file in the day or so after its expiry; the jobs storage keeps no earlier version of a file and is in no backup. You may delete a job, its file and its result sooner. Batch jobs take test keys only, for invented data.

If you sign in to the console, the sign-in is held by Amazon Cognito, a service of Amazon Web Services, which hosts Payerworks under our business associate agreement with it. It keeps your email address and your name, and checks your password and a code from your authenticator app at every sign-in; your password is sent to Amazon Cognito and never to Payerworks. Your sign-in lives in the page’s memory only and ends when you reload the page or sign out. An organization is kept while it exists: its name, its members (each sign-in’s email address, name and role) and its pending invitations (an email address and a role, for 7 days). Never a claim, a patient or the body of a call. An invitation is emailed by Payerworks in fixed words that name neither the organization nor who invited, and its link works for 7 days, only for a sign-in at the address it was sent to.

Payerworks keeps a record of each change to your account (who made it, when, through which door, and the names of the fields that changed, never their contents) for one year, then deletes it; you can read and download it with GET /v1/audit-log. A change Payerworks’ own people make says Payerworks, never a person’s name.

No account can send claims through Payerworks while it is connected to no payer. Once one can, for each file an account sends with POST /v1/claims/submit we keep the claim references and control numbers it carries, the account and key that sent it and what became of it, for 400 days; the file as sent is kept, and nothing in the product deletes it; the answer to that call is kept for a day, so that a retry under the same Idempotency-Key is answered the same and sends nothing again; and the events a partner’s answers make are kept for 30 days, like every event, and go only to the key that sent the file.

The Site runs no advertising or analytics tags. No cookie is set to measure you, no advertising network receives anything about your visit, and no consent banner is drawn because there is nothing to consent to. The servers that answer the Site keep the ordinary request records every web server keeps, the network address a request came from, the page asked for and the time, and use them only to keep the Site up and to investigate abuse.

Please keep patient information out of the forms, out of the sandbox and out of email. A payer name, a transaction set and a question are all a reply needs, and the sandbox takes invented claims only. Identifiers travel inside the files, under an agreement, and nowhere else.

Payerworks holds the files a trading partner or a customer sends to its own endpoint under an agreement: professional claims, remittances, acknowledgments, interchange answers, eligibility questions and answers, and claim status questions and answers, in the X12 formats the industry uses. Each file is held on behalf of the organization that sent it or is to receive it, a billing team, a provider, a payer, a network or a service vendor, and each of those organizations is bound to us by a written agreement before a single file carries a patient.

What the Payerworks API is sent is different: a claim, a file or a remittance sent to it is answered and not kept, apart from what the section above lists (the counts, the webhook and its destinations, its events and their deliveries, the notice address and the notices waiting for it, the keys, the request fingerprints, what you create through the enrollment routes, and a file dropped over the API’s SFTP file drop until its answers are written, and a batch job’s file until the job finishes and its result for 24 hours, an organization and its members, the audit log, and what an account’s own sends keep).

For the billing teams and providers it serves, Payerworks is a business associate under HIPAA. The business associate agreement, not this policy, governs every aspect of the protected health information (“PHI”) in those files: the permitted uses and disclosures, the minimum necessary standard, the safeguards, workforce training and access, subcontractors, breach notification and audit rights. For the payers and networks it connects to, the trading partner agreement governs the files in the same way.

Payerworks uses the files for one purpose: to carry them, read them, match them and account for them for the organization they belong to. It does not sell them, does not share one organization’s files with another, does not use them to build benchmarks or products without written consent, and does not let a vendor use them for the vendor’s own purposes.

What a payer or a customer sent is the record, and the archive is built so that a dispute years later is answered from the file rather than from memory. Every file a trading partner or a customer sends to the Payerworks endpoint under its agreement is kept as it was sent, every version is kept, and no function in the product can delete one. The API’s SFTP file drop is not that archive: a file dropped there is deleted once its answers are written, and its answers after 7 days, as the section on what the Site collects says. Files are kept for as long as the agreement that governs them, applicable federal and state law and the payer’s own requirements direct, and the documentation HIPAA requires, including the agreements themselves, is kept for at least six years from the later of its creation and its last effective date.

When an agreement ends, PHI is returned or destroyed as that agreement directs. Where the archive’s design makes return or destruction of a copy infeasible, we say so, extend the protections of the agreement to that copy for as long as we keep it, and use it for nothing beyond what makes keeping it necessary.

An organization sees its own files and nothing else. Within Payerworks, a person sees what their role needs: staff who do not work a lane cannot open it, every person signs a confidentiality acknowledgment before their first sign-in, and sign-in requires a second factor. The functions that move a trading partner’s or a customer’s files under its agreement run under a role that can read them and cannot delete them.

Every action that changes a record is written to an audit trail that names the person or the function, the time and the row, and never the patient, so the trail can be read by an auditor without becoming a second copy of the data it describes.

A small number of vendors operate the infrastructure beneath Payerworks, such as the cloud provider that hosts it. Payerworks sends no file to a payer yet and routes none through another clearinghouse. Each vendor that could touch health information signs a business associate agreement with us first, is limited to the minimum necessary to perform its function, and is restricted from using anything it handles for its own purposes.

Every file and every record is encrypted at rest under keys that belong to us, and every transfer runs over an encrypted connection. A file a trading partner sends under its agreement arrives over SFTP under the partner’s own key, in the partner’s own folder, and lands encrypted. Data is backed up daily and across regions, and the backups are restored on a schedule into disposable encrypted copies so that a backup is a tested thing rather than a hope. The controls are described for a reviewer on our security page. Payerworks names an independent attestation only once it is issued; until one is, it claims none.

A trading partner or a customer may ask, in writing, what Payerworks holds for it, ask for a copy, ask for a correction, ask for deletion where the governing agreement and the law allow it, or ask for an accounting of the disclosures made of its files. Send the request through the form on any page of this Site, or to the contact named in your agreement, and say which organization you are writing for. We acknowledge a request within five business days and answer it within thirty calendar days.

A patient’s own rights under HIPAA, including access, amendment and an accounting of disclosures, belong with the provider or the health plan that holds the patient relationship, not with Payerworks. As a business associate, Payerworks supports those rights only as that organization directs and within the terms of its agreement. A patient who writes to us is pointed to their provider or plan.

A person who used the Site’s form may ask us to correct or delete what they typed, through the same form. California residents may have further rights under the CCPA and the CPRA; to the extent those apply to Payerworks, they may be exercised the same way.

If you believe a file has been exposed, an account misused or the Site compromised, tell us at once through the form on any page of this Site, saying that you are reporting a security concern, or through the security contact named in your agreement. A person reads it, and it reaches the officer responsible for security. Where an incident involves PHI, the organization whose files are affected is notified within the time its agreement states and in the way HIPAA requires.

Payerworks updates this policy when its practices change or when the law requires it. A material change is posted here with a new effective date. The agreements that govern the files are not changed by a change to this policy.