Security and compliance, as it stands today.

• Real patient records only under BAAs

  Every upload is marked synthetic, de-identified or covered by a BAA. The app refuses real records until the AWS BAA and your BAA with Schema Care are both in place. The AWS BAA is not accepted yet, so today it takes synthetic and de-identified files only.

  Not yet

• A separate AWS account for health data

  The app at app.schemacare.com runs on AWS in us-west-2, in an account kept apart from our tax and accounting products. This marketing site is hosted elsewhere.

  In place

• Encryption at rest and in transit

  Files are stored in S3 under a dedicated KMS key, and the bucket refuses any request without TLS. Download links expire after five minutes.

  In place

• Multi-factor sign-in and short sessions

  Every session needs an authenticator app code, with one-time recovery codes as backup. Sessions end after 15 minutes idle or 12 hours in all.

  In place

• Access by role and matter

  Owners and admins see every matter in the workspace. Reviewers and viewers see only the matters granted to them.

  In place

• An audit log you can export

  Views, downloads, reviews, role changes and deletions are recorded with who and when. Owners and admins can read the log and export it as CSV.

  In place

• Retention you set

  Choose 1 to 3,650 days. When it runs out, the document, its pages, facts and outputs, and every stored version of the file are deleted.

  In place

• Independent security audit

  No third-party assessment has been done yet, and Schema Care has no SOC 2 report.

  Planned

Every upload has to be marked as one of three things: synthetic, de-identified, or real records covered by a business associate agreement. The app checks that choice before it issues an upload link.

It accepts real records only when two agreements are in place: the AWS BAA for the account that stores and processes them, and your BAA with Schema Care. The switch that allows real records stays off until the AWS BAA and our other vendor BAAs are accepted. Today it is off, so the app accepts synthetic and de-identified files only.

Inside the app, each workspace’s Compliance page shows whether the AWS BAA is accepted and whether your BAA with us is signed.

The app at app.schemacare.com runs on Amazon ECS in AWS’s us-west-2 (Oregon) region, inside an AWS account set up for health data and kept apart from our tax and accounting products. Uploaded files are stored in Amazon S3 in that account.

The account blocks public access to S3 for every bucket, turns on versioning and access logging for its buckets, and records API activity with AWS CloudTrail. Amazon GuardDuty watches it for threats. Deploys run from our main branch through a short-lived GitHub role, not stored AWS keys.

Workspaces, matters, page text and extracted facts are kept in a Postgres database at Neon.

This marketing site, schemacare.com, runs in the same AWS account as the app but at its own address, and uses an analytics script. That script loads only on the marketing pages and the blog, never on sign-in, MFA or dashboard pages, which answer only at app.schemacare.com, and an automated test fails the build if that changes.

Files in S3 are encrypted at rest with server-side KMS encryption under a key used only for this health data account. A browser upload goes straight to S3 through a signed policy that fixes the file’s name, type, size and encryption key. The bucket also rejects any file not encrypted with that key.

The bucket refuses every request that does not use TLS, and the app is served over HTTPS. Upload and download links expire after five minutes. Storage paths carry only random ids, never a patient or matter name.

The copy of the audit log in AWS CloudWatch is encrypted with the same key. Authenticator secrets are encrypted with AES-256-GCM and bound to their user.

You sign in with Google, a GitHub account through JustAuth, or a link sent to your email. Every session then needs a code from an authenticator app before any record is shown. At setup you get eight one-time recovery codes for a lost phone.

A session ends after 15 minutes without activity and 12 hours after sign-in, whichever comes first. Both limits are checked on the server on every dashboard request.

Each workspace has four roles. A reviewer or viewer sees a matter only after an owner or admin grants it, and every grant and revocation is logged.

Owner

Everything an admin can, plus workspace settings: retention and the review threshold.

Admin

Every matter in the workspace. Creates matters, grants access, uploads, reviews facts, reads the audit log, manages the team.

Reviewer

Only the matters granted to them. Uploads documents and approves or corrects facts.

Viewer

Only the matters granted to them, read only.

The app records who did what and when: opening a matter, document or fact, requesting an upload or download link, approving or correcting a fact, granting or revoking access, inviting, removing or changing the role of a team member, changing settings, exporting the log, and every deletion.

Owners and admins can read the log in the app, filter it by action, and export it as CSV. Each event is also copied to AWS CloudWatch Logs in the health data account, kept for six years.

Each workspace sets how long documents are kept, from 1 to 3,650 days. The default is 90 days. Changing it reschedules every document already in the workspace.

When a document reaches its date, the app deletes it with its pages, facts and generated outputs, and removes every stored version of its files from S3. The deletion itself is written to the audit log.

Amazon Textract reads each page in the same AWS account and region. Claude, through Amazon Bedrock, then pulls out dates, providers, diagnoses, procedures and medications. Bedrock is called with a US cross-region inference profile, so a request may be served from another AWS region in the United States.

The model gets the page text and one way to answer: a fixed output form. It has no tools that act and no network access. A fallback through the Anthropic API exists, and the app refuses it for any file not marked synthetic, because Anthropic has no BAA with us.

Every fact the model returns must cite one page and quote the words that support it. The app checks that those words are on the cited page. A fact whose quote is not found, or whose confidence is under your workspace’s threshold, goes to a person in the review queue instead of straight into your summary.

The workspace owner sets the threshold between 50 and 100. The default is 90. Each approval and correction is logged with who made it and when.

From the dashboard you can load a demo matter of fictional record sets that we generate ourselves. Every page says it is fictional, so you can try the whole pipeline without uploading anything real.

• The AWS business associate agreement is not accepted yet.
• The database at Neon is not yet under a BAA.
• Our customer BAA template is drafted and waiting on review by counsel.
• Our HIPAA policies, risk analysis and incident response plan are drafts that counsel has not reviewed.
• No independent security assessment or penetration test has been done, and there is no SOC 2 report.
• Single sign-on, listed on the Enterprise plan, is not built yet.

To ask about a BAA or a security review, or to report a security issue, write to hello@schemacare.com. Please don’t email medical records. That address is not covered by a BAA.