Security and HIPAA

Where the insurance details go, in plain English.

A client types a member ID into a box on your website. This page follows it from there, and says what we keep, what we never keep, and what we have not finished yet.

We are your business associate

The moment a check runs, we create, receive and transmit protected health information on your behalf. Under HIPAA that makes us your business associate and you the covered entity, even if your practice has never billed insurance before. Checking eligibility is a payment activity, so the client does not need to sign an authorisation for it, and the minimum-necessary rule applies: we collect only what the inquiry needs and we never echo the plan's full response back to the client.

If your practice has been cash-pay until now, the first electronic eligibility check is the moment HIPAA starts applying to you. We say so during onboarding and point you to a notice of privacy practices, because that is the kind of thing a front desk should hear before it happens, not after.

The business associate agreement comes before the key

You accept our business associate agreement during signup, before an API key is issued. No agreement, no key. It covers the elements HIPAA requires of a business associate: permitted uses, safeguards, subcontractors held to the same terms, breach notification within 72 hours of discovery, your right to the data, and return or destruction when the relationship ends. Enterprise customers get the same agreement countersigned, with custom terms where their counsel needs them.

We hold matching agreements upstream with our cloud provider, our clearinghouse and the provider of the model that writes the explanations. The clearinghouse carries the inquiry to the plan; nobody else in the chain sees a member ID.

What a check touches, and what we never keep

The client enters six things: the carrier, the member ID, the date of birth, the state, the type of care, and the clinician if you have more than one. They tick a consent box whose sentence is stored word for word with the check.

  • Used once, then dropped: the full member ID and the full date of birth. They travel over an encrypted connection to our API and on to the clearinghouse, and they are gone from memory when the plan answers. Our logs redact both at every depth.
  • Kept for you: the last four characters of the member ID, the birth year, the carrier and plan name, the status, the figures the plan reported, the sentence the client saw, the client's contact details if they left them, the consent record and the time of the plan's response.
  • Never created: a copy in the client's browser. The widget writes nothing to local storage, cookies or the address bar, and the usage events it sends carry no member ID and no date of birth.

The raw plan response is kept for a short period so a disputed result can be checked against what the plan actually said, then deleted on the schedule below.

Encryption and access

  • Everything in transit is encrypted. The widget refuses to send a check over plain HTTP anywhere except a local development machine.
  • Everything at rest is encrypted on Google Cloud, inside the services Google covers under its own business associate agreement.
  • Portal logins use multi-factor authentication. Enterprise plans add single sign-on.
  • API keys are stored only as salted hashes. A key is shown to you once, at creation, and can be rotated or revoked from the portal at any time.
  • Every read and write of a check is logged centrally, with who did it and when.

Retention

Retention schedule by record type
RecordKept for
Full member ID and date of birthNot stored. Used for the inquiry and dropped.
Raw plan response90 days, then deleted
Result summary, consent record and lead details24 months, or until you delete them
Everything above, after you cancelExportable for 30 days, then hard deleted
The agreement and compliance recordsSix years, as HIPAA requires

The widget carries no trackers

There is no pixel, no analytics script and no session replay inside the widget, on the hosted checker, or on any page where a client types insurance details. The widget renders inside its own isolated style scope, so your site's styles do not reach its fields and its fields do not spill into your page. The badge at its foot is a plain link.

The marketing pages you are reading now are the only pages that may ever carry an advertising tag, and this sample site carries none.

Deleting data

  • Delete a single check from its page in the portal. The summary, the lead details and the consent record go together.
  • Delete everything from the settings page, or by cancelling: your data stays exportable for 30 days and is then hard deleted.
  • A client can ask you to delete their check; you can do it yourself in the portal, or ask us and we will do it within 10 business days.

What we are not yet

Honesty about the gaps is part of the posture.

  • No SOC 2 report yet. A SOC 2 Type 1 audit is planned for our first large group or EHR-marketplace customer, with Type 2 a year later. A third-party penetration test comes before the audit.
  • No HITRUST certification, and none planned until a payer or health-system contract requires it.
  • Our written risk analysis and policy set are being completed before the first paying customer, not after.
  • One legal question is still with counsel: whether converting a form into a standard eligibility transaction makes us a clearinghouse as well as a business associate. We are building as if the stricter answer is true.

When any of these changes, this page changes with it.

Questions this page did not answer?

Ask them during signup. We would rather answer them before you paste the snippet than after.