Trust

Security & confidentiality

Your manuscript is unpublished work. Here is exactly how we treat it — stated plainly, and limited to what the system actually does.

Last updated 2026-06-15
Version v1.0

§01 Quarantine, then promote

Every upload lands in quarantine storage first and is screened before it is promoted to durable storage. Screening records its verdict and any identifier categories it detects — never the matched values — and those results are retained for audit. Two things block an upload outright: files that exceed our size cap or parse bounds (resource protection), and files that fail malware screening — those are quarantined and never processed, and a paid submission they belong to is refunded. Identifier screening (next section) is advisory and never blocks.

§02 PHI screening on every upload

Each file is screened for patient identifiers before promotion. Screening is advisory: it warns you and creates an audit record, but it does not reject your files. Instead, you attest at submission — exactly as journals require — that the work is de-identified, and that attestation is recorded, timestamped, with your submission. Image files, such as figures, cannot be text-screened and are accepted under the same attestation. Screening reduces the risk of identifiable health information passing through; it does not eliminate it. Submit de-identified manuscripts, as you would to a journal. RigorMD is not a HIPAA covered entity or business associate and does not enter into BAAs; submit de-identified manuscripts only.

Today's screen is deterministic and covers a subset of the HIPAA Safe-Harbor identifier families (8 of 18); deeper name- and date-level detection is on our roadmap. Manuscript text is analyzed by our two engine providers, Anthropic and OpenAI, through their commercial APIs, which do not use API submissions to train their models. Cited reference identifiers (DOIs and PMIDs) are additionally verified against the public registries — Crossref, NCBI, and the DOI Foundation — by bare identifier only; manuscript text is never sent to them.

§03 Tenant isolation and who can see a report

A manuscript, its report, the findings, their severities, and even the storage locations are visible only to the author and any recipients the author explicitly names. Row-level security enforces this in the database itself, on every content table, under non-privileged database roles — not just in application code — and report access is logged.

The same boundary holds for the surfaces built for organizations. If an author belongs to an institution, that institution's administrators see adoption and activity only — counts and status — never titles, manuscript content, severities, or findings. The platform operator sees aggregate, redacted metrics to run the business, never your content. Your work is not projected onto any dashboard but your own.

§04 Encryption in transit and at rest

All traffic between your browser, our services, and our processors is encrypted with TLS. Manuscript files, processing artifacts, and reports are held in an S3-compatible object store that encrypts data at rest, and the application's database connections run over TLS as well.

§05 Operational confidentiality

Notifications are content-free. A report-ready email tells you a report is ready and links you to your dashboard — it never carries your manuscript title, your findings, or their severities. The report itself lives behind sign-in.

Our error monitoring exists to keep the service reliable, and it is configured to leave your work out of it: no manuscript text, identifiers, report contents, signed links, or model prompt-and-response bodies are sent to it. It records no session replays and no personally identifying information — only technical diagnostics and timing. Logs are written to the same standard: never manuscript text, identifier values, storage keys, or signed URLs.

§06 Retention and purge

Submissions are retained for 90 days by default. Past that window a submission is expired, and after a 7-day grace period its content — manuscript files, processing artifacts, reports, and findings — is purged from storage and from the database, with an audit record of the purge. Billing and audit records are preserved; manuscript content is not. Deletion requests are honored on the same purge path.

§07 No training on your manuscripts

We do not train models on your files. Analysis runs through the commercial APIs of our model providers — not consumer chat products — and the providers we use are listed on our data processing page.

Plain-English summary. This page describes the system as built and is kept current as the platform evolves. See also Privacy and Terms.