Frequently asked questions

Files that look like a clinical record — the columns and coding of a healthcare export — are processed with clinical identifier coverage for the HIPAA Safe Harbor identifiers, after you complete a Business Associate Agreement attestation step (before any payment).

You can also decline. Declining does not change the identifier coverage applied — the file is processed exactly as it would be otherwise. What it changes is the legal basis: the agreement does not take effect for that file, and you are asserting that the file does not contain Protected Health Information. The declination is recorded with the job.

Files that indicate health data are routed to the attestation step before processing — including a file that trips a health-data signal without the full clinical structure (say, a stray SSN column in an otherwise general file). You either accept the Business Associate Agreement or state that the file contains no Protected Health Information. Either way the file is processed and the choice is recorded with the job. Not sure which applies to your file? Contact us.

PDM performs the de-identification step Safe Harbor calls for — it detects and masks the Safe Harbor identifier categories in structured columns and in free text. It does not issue a determination that your file is de-identified. That judgment stays with you: you remain the covered entity, PDM is a business associate. There is no HIPAA certification for a tool, either — compliance is a property of your organization’s processes, not a badge a vendor holds.

The distinction is sharpest at identifier 18, “any other unique identifying number or characteristic.” That's a judgment standard about your data and your context, not a pattern any detector can match, so it sits outside what an automated tool can decide for you. The codes we do plant and test under it are measured with every other category on our detection results page.

Yes. When a file routes as clinical we ask you to attest to the Business Associate Agreement before payment, and declining is an explicit, recorded option.

Attesting puts a Business Associate Agreement in place before the file is processed. HIPAA requires a written agreement before a covered entity discloses PHI to a service provider, and that is what the attestation is for. It does not change what gets masked.

If you decline, the file is processed exactly as it would be otherwise — declining does not change the identifier coverage applied. What it changes is the legal basis: the agreement does not take effect for that file, and you are asserting that the file does not contain Protected Health Information. The declination is recorded with the job, and if you attest the receipt records the agreement version and the time you attested.

It's a real Business Associate Agreement, accepted by attestation. The full terms are at /legal/baa. An authorised representative of a covered entity accepts them when submitting a file for clinical coverage, and a separate signature is not required for them to take effect — they're standing terms that apply to each file submitted under them.

If your compliance process needs a countersigned copy on file, request one and we'll provide it. The receipt records which version you accepted and when.

Two, and they do different things. Google Cloud provides the infrastructure your file runs on: Cloud DLP performs part of the detection, Cloud Storage holds the file while the job runs, and a Cloud SQL database holds job metadata. DLP is a Google-managed API, covered by Google's data-processing terms. Stripe processes payment and never receives your file — we never see your card details either.

Our own detection model is not a third party: it runs on our infrastructure with its weights built into the container image.

Nothing else touches your file. No analytics vendor, no error-reporting service, no subcontractor. Where a Business Associate Agreement is in effect, subcontractor obligations flow down as 45 CFR 164.502(e)(1)(ii) requires. Our /trust page maps the whole boundary.

Presidio is an open-source PII detection library — well-built, widely used, and free. It's designed to be adapted: you assemble a configuration for your domain, host it, and integrate it.

PDM ships assembled. You upload a file and get a masked one back with a processing receipt. No installation, no configuration, no deployment.

Both use the word “recipe,” which is a useful place to see the difference. In Presidio, a recipe is a worked example you follow to build a setup for your data. In PDM, a recipe is a frozen, versioned configuration the product selects for your file automatically — clinical, financial, or general — based on what's in it.

The rest follows from that. PDM runs inside a sealed cloud environment with a Business Associate Agreement available for PHI, which a library you host yourself can't provide. Every job returns a receipt tied to your specific file by cryptographic hash.

If you're building a data pipeline, Presidio is a reasonable choice. If you have a file that needs to go somewhere, that's what PDM is for.

PDM scans every row and column with layered detection: Google Cloud DLP handles structured columns and shape-based identifiers, our own validators add format-specific checks, and our self-hosted model handles names and locations written into prose. Our model runs on our infrastructure; DLP is a Google Cloud service covered by Google’s data-processing terms.

No automated system can guarantee catching every possible format of sensitive data, so review your masked file before relying on it for anything where a missed value would matter. We publish measured coverage — including the categories we don’t detect at all — on our detection results page. Full details are in our Terms of Service.

Over-masking is when a value that identifies nobody — a drug name, a room number, a lot code — is masked anyway: no HIPAA requirement is failed, and the data loses its use. PDM measures it against look-alike values planted deliberately in the test files, and the results are on our detection results page.

It's when part of an identifier is masked and part of it survives — an IP address coming back as [MASKED].234.61.189, for instance. The surviving fragment can still carry identifying information, so a partial mask isn't a partial success.

We count them as misses. Every coverage figure we publish uses the same rule: a value counts as caught only when the mask covers the whole value. In our most recent measurement, 32 of 10,019 planted identifiers were partially masked, and all 32 count against us. Full figures are on our detection results page.

Every completed job returns a receipt alongside your masked file. It records the job ID and file name, row and column counts, how many cells were masked and by identifier type, which processing configuration ran and what the file routed as, the completion time, and — where clinical coverage applied — the BAA version and the time you attested.

It also carries SHA-256 hashes of both your original file and the masked one. To check them, hash your own copies and compare: shasum -a 256 yourfile.csv on macOS or Linux, certutil -hashfile yourfile.csv SHA256 on Windows. If they match, the receipt provably describes the exact files you're holding — verifiable by anyone, without taking our word for it.

Right now, up to 5,000 rows and 10 MB in a single file. That's a certification frontier, not a technical wall: we publish a size only once we've certified masking quality and timing at that size, and we raise it one step at a time — we certify what we publish, then larger files as we certify them.

Free-text-heavy files (notes, transcripts) are the most demanding — we read whole sentences rather than just checking a format — but the same 5,000-row / 10 MB ceiling applies to every file, and we scan every column to confirm nothing was missed.

If your file is larger, split it into smaller batches and submit each separately. We'll tell you before you pay if a file is over the current limit.