How PDI Med protects your data

PHI stays in your vault. Intelligence travels.

Your vault’s contents — your original notes, committed encounters, drafts, and the map that links placeholders like [NAME_1] back to real identifiers — are encrypted in your browser with AES-256-GCM before they reach our servers. The key is created in your browser and is unlocked only by your passkey (Face ID / Touch ID), your 12-word recovery code, or a passphrase if you add one.

We store the encrypted vault and wrapped copies of the key that we cannot open; our servers hold no key that can decrypt it. No one at PDI Med can read your vault’s contents, and if you lose your recovery code and every passkey, no one — including us — can recover them.

Parsing a note. Your browser replaces identifiers with placeholders and you review the result before anything is sent. The de-identified text travels over TLS to our servers, which block recognizable identifiers such as Social Security numbers, dates of birth, record numbers, phone numbers and addresses, and then to Claude on Amazon Bedrock, inside our own AWS account and covered by our Business Associate Agreement with Amazon. It is never sent to Anthropic, and we do not keep the note. No automated de-identification is perfect: an identifier that the software and your review both miss will reach our servers and the model.

Your case-log data. So the app can list and organize your cases, our servers keep de-identified details from each encounter — diagnoses, medications, procedures, lab names and values, ABOG categories, visit purpose and tags — and the date of service, linked to your account and to a patient code only your vault can resolve. We treat this as protected health information: it is encrypted at rest with AWS keys, isolated to your account, and accessible only to PDI Med’s operator. When you download an ABOG-format case list, your browser builds the file from your vault; our servers receive only a record that you exported it (the format, the section and the number of rows).

Your account. Email, profile, the state of each practice location you name, and sign-in records. Passwords are stored as Argon2id hashes, every account requires an authenticator app, and registration is by invitation only.

Activity. When you sign in, save, commit and export.

The software. We deliver the code that encrypts your vault, so altered code could capture your key when you unlock. Before every release we publish a fingerprint of our core encryption files to Sigstore, a public transparency log we do not control, so a substitution can be detected after the fact. This code has not yet had an independent security review.

Two separate locks. The first three steps prove to PDI Med’s servers who you are and open your account. The vault is a second lock that only your browser can open — PDI Med’s servers never take part and never see its secrets.

1. Password. Opens your PDI Med account. It does not open your vault. We store only an Argon2id hash of it.

2. Authenticator code. Required for every account, so a stolen password alone is not enough. Codes come only from your authenticator app; we never send a sign-in code by email. If you forget your password, use “Forgot password?” on the sign-in page with a code from your authenticator. If you lose your phone, contact us: once we have confirmed it is you, we send you a one-time link to set up a new authenticator, which also needs your password.

3. “This is my own private device.” Tick it only on your own computer. It skips the code on that browser — for 7 days after each use, up to 90 days — and for 24 hours after you sign in with it ticked your password alone works on other computers — so moving between hospital workstations during a shift isn’t a chore.

4. Face ID / Touch ID (passkey). Unlocks your vault in your browser. This is the step PDI Med cannot do for you: your password and code — even a password reset — do not open the vault.

5. 12-word recovery code. Your offline way in if you lose your devices. It is shown once, and we cannot show it again or recover it.

Automatic lock. Your vault locks when you sign out, and after 60 minutes without activity. Closing the tab does not lock it right away, so always sign out on shared computers.

1. You paste a note. Your browser replaces names, dates and other identifiers with placeholders such as [NAME_1]. The map from placeholders back to real details stays in your browser, and inside your encrypted vault once you commit.

2. You review the de-identified text and confirm it before anything is sent.

3. The de-identified text goes to PDI Med over an encrypted connection (TLS 1.2 or higher). Our servers check it again and refuse recognizable identifiers.

4. We send it to Claude on Amazon Bedrock, inside PDI Med’s own AWS account in the United States. It is never sent to Anthropic. Bedrock’s prompt logging is switched off, so Bedrock keeps no copy of the text in our AWS account.

5. The structured result comes back with placeholders, not names. Your browser puts the real details back — on your screen only.

6. When you commit, your browser encrypts the full note and the placeholder map into your vault. Our servers keep only the de-identified case-log details described above.

What has to be in place. A Business Associate Agreement between PDI Med and Amazon Web Services that covers Amazon Bedrock (executed August 2026 and confirmed active); only models covered by that agreement (Claude Sonnet and Claude Haiku); your Business Associate Agreement with PDI Med; and your review of the de-identified text.

PDI Med is built so that your browser does the work wherever it can. When a feature needs the AI model, our servers send it only what that request needs, in the least revealing form that answers it: codes, counts or short clinical labels where those are enough, and de-identified text only where the model has to read the clinical story, such as parsing a note or asking you about a case. What is sent to the model is de-identified, used only to answer that request, and not kept in readable form. Location. The only location detail PDI Med keeps is the US state. For you, our servers keep the state of each hospital or practice location you name, for example your main hospital and a locums site; their names, addresses and cities, and your default location, stay in your vault. For a visit, the facility, the site of service and the time of day stay in your vault, and the app does not send them to our servers (anything an older open page still sends is discarded before use); the date of the visit is kept with its clinical labels, as listed above; a facility you entered that appears in text leaving your browser is replaced by a token first. What we do keep:

A one-way fingerprint of what was sent, for our audit record, with the model, the size, the outcome, and the kinds (never the values) of anything our identifier check flagged. A fingerprint cannot be turned back into text, but it could be used to confirm a guess of short, predictable text. A few calls do not write one yet.

Some results in server memory, such as a finished parse until your page collects it. They are never written to disk and are lost when the server restarts.

Request metadata: the time, destination and size of each request and the kinds of pattern our scan found, never the text.

Every place PDI Med calls an AI model is declared in a register of what it sends, in what form, and what our servers keep. Our release checks scan our server code for model calls and stop a release when they find one the register does not declare. The model is Claude on Amazon Bedrock, inside our own AWS account and covered by our Business Associate Agreement with Amazon. Bedrock’s prompt logging is off, and a release check looks for code in our repository that would turn it on. Our full standard, “Minimum necessary: how PDI Med sends anything to a model”, lists each call, what it sends and keeps, where we do not yet meet the standard, and our roadmap; email dan@pdi-med.com for a copy.

What this does not claim. De-identification is multi-layer, with your review, and is not perfect (see “Parsing a note” above); when our check flags something in a Refine question, you decide whether it is sent. For source suggestions, your browser sends the case’s diagnosis, procedure and complication labels as your Case List shows them, and our servers remove identifiers from them before the model call, so for that call our servers briefly hold those labels before de-identification. During any call, our server holds that call’s text in memory; it is released, not wiped, when the request ends. And whoever operates PDI Med’s servers (today, the founder) can reach the running server, so a request in flight is protected by access controls and by our agreement with you, not by hardware that locks the operator out. Running AI calls inside an attested, isolated enclave is on our roadmap.

Vault export. Built in your browser: our servers send only encrypted data, and your browser decrypts it and saves your full record to your computer, with a manifest of fingerprints so the file can be checked later.

ABOG-format case list. CSV, Excel and the ABOG templates are built in your browser from your vault; our servers send the blank template and receive only a record that you exported (the format, the section and the number of rows).

ABOG verification packet. Built entirely in your browser.

Once a file is saved, it is on your computer and PDI Med’s protections no longer apply to it — you are its custodian. It contains your patients’ information: store it encrypted, keep it out of personal cloud storage and email, and delete copies you no longer need. We record that an export happened and what we produced, not where the file goes.

Sigstore public transparency log. Before every release, a fingerprint of our core encryption code; about every six hours, the fingerprint of our audit ledger, so a rewrite of any earlier entry would show. We cannot edit or delete these entries. The current fingerprints are published at app.pdi-med.com/.well-known/pdi-crypto-manifest and app.pdi-med.com/.well-known/pdi-ledger-head.

Certificate Transparency logs. Every security certificate issued for app.pdi-med.com is recorded in public logs, so a certificate issued to anyone else for our domain would be visible.

Amazon Web Services. Our Business Associate Agreement with Amazon is recorded in AWS Artifact, which Amazon holds.

Your own exports. Each vault export carries fingerprints of what we produced, so you can later show the file is unaltered.

What these do not prove: they show that records were not quietly rewritten and which code was released. They do not prove that every entry is true, and no one outside PDI Med monitors the log yet.

Encrypted connections. TLS 1.2 or higher, with HTTPS enforced.

Encrypted storage. Everything we store is encrypted at rest with AWS encryption keys, with public access blocked, on Amazon Web Services in the United States under our Business Associate Agreement with Amazon. Backups run daily and expire after 35 days.

Sign-in. Argon2id password hashing; an authenticator app on every account; invitation-only registration; limits on repeated guesses; sessions that end after 60 minutes without activity or at 24 hours, in secure, HttpOnly cookies.

Isolation. Every request is bound to your account, and other physicians’ data is not reachable from yours.

Code integrity. Every script file loaded on the pages that handle your vault is pinned by a cryptographic hash, and our core encryption files are fingerprinted in a public log before each release.

De-identification. Multi-layer de-identification with physician verification: browser tokenization, your review before every submission, and a server check that refuses recognizable identifiers.

Operator access. PDI Med has one person with production access, the founder, and no support tool can open a vault.

The code that encrypts your vault has not yet had an independent security review or penetration test. De-identification is not perfect, which is why your review is part of every encounter. PDI Verify is our own testing method, not an independent certification. There is no government certification for HIPAA software, so we describe specific controls instead of calling the product “HIPAA compliant”.

Patient consent: not under HIPAA, for how PDI Med is used. Continuity of care is treatment. Preparing your ABOG case list is health care operations, whose definition names certification, credentialing and training (45 C.F.R. 164.501). A covered entity may use patient information for its own treatment and health care operations without the patient’s consent (45 C.F.R. 164.506), and may share it with a business associate under a Business Associate Agreement, which PDI Med signs with you. Your practice’s Notice of Privacy Practices already covers these uses, and they are exempt from the accounting of disclosures. PDI Med does not record visits, so audio-recording consent laws do not apply. The case list you submit to ABOG carries no patient identifiers except age; ABOG asks you to keep your own record of who each patient is in case of an audit, and your vault is that record.

Your employer: yes, if you are employed. When a hospital or group employs you, it is the covered entity and the patient information belongs to it, so the permission that matters is your employer’s, not your patients’. Confirm with your privacy or security officer that you may use PDI Med. After you sign up, PDI Med gives you an approval link to send them: it opens a page describing how PDI Med handles patient information, and they type their name and click Approve. If they prefer paper, send them our one-page security and privacy summary (PDF) instead: a typed signature or a reply of “Approved” is enough, and you upload their copy on your profile page. Either way the approval stays in your encrypted vault: PDI Med cannot read it and never learns who your employer or officer is, and your patient features unlock as soon as it is filed. PDI Med records only that you filed it, and when; because it cannot read the approval, filing it is your confirmation that it is your employer’s approval. If you are in private practice, you are the covered entity and the decision is yours.

When patient authorization would be needed: research, publishing cases, marketing or selling data, unless the data is de-identified under HIPAA (which is why Network contribution stays off until an independent expert determination); substance use disorder treatment records protected by 42 C.F.R. Part 2; and, under some state laws, particular categories such as HIV and STI results, genetic tests, mental health, and a minor’s confidential reproductive care when shared outside treatment. This is a summary of the rules, not legal advice.

If we are legally compelled to produce data, we can produce only what we hold: your encrypted vault, which we cannot decrypt, and the readable items described on this page. Where the law allows, we will tell you first.