How Capnolog handles your data

Capnolog is an independent phone app for iPhone and Android, built from one codebase, with an optional browser extension, for residents and for medical students. A Mac companion is in development and is not available yet. One free account links your devices; it holds an id and your training program, never your name. You are the controller of your own log, and the full log with your private note lives on your device. By default, your de-identified case log (the same fields your CSV export carries, plus whether each case has been filed with the ACGME — never your private note) syncs through our zero-PHI backend, so case tracking and roster sync work automatically. You can turn that off at any time in Settings → Data, backup & export (the app’s one-time notice offers the same Turn off button); turning it off purges the data from our servers and the app falls back to on-device-only (you can still export your case log as a CSV for your own records). A small zero-PHI service also keeps your program’s de-identified roster (site and attending lists) in sync across residents. Neither service ever receives a patient identifier — see De-identified case sync and The ACGME autofill browser extension below.

Who the controller is. Capnolog is a trade name of Chockstone Labs LLC, an Ohio limited liability company, which operates the service. That company is the controller of the data described in this policy. Legal notices can be mailed to Chockstone Labs LLC, 46 Shopping Plaza, PMB 5052, Chagrin Falls, OH 44022, USA. You can also reach us at privacy@capnolog.com for privacy and at support@capnolog.com for everything else.

Who it is for. Capnolog is built for medical students, residents, and fellows training in the United States, and for the US programs that train them. Outside the United States it is not directed at you and we do not support it. If you use it anyway, see If you are outside the United States below — we will still answer a request about your data.

Your choices, and what each one defaults to

Four things are switches, and it matters that you know which way they start. Accepting the Terms of Use is not one of them: it is required to use the app. Everything in this list is optional, lives at Settings → Data & privacy, and can be changed as often as you like.

• De-identified case sync — on by default. Settings → Data & privacy → Data, backup & export. The app also tells you once, the first time it is usable, and that notice carries the same Turn off button. Turning it off deletes our copy from the server; the browser extension and cross-device tracking depend on sync, and the Log tab shows a reminder while it is off.
• Research sharing — on by default. Settings → Data & privacy → Research sharing & analytics. This is the only source of the anonymized statistics described below. Turning it off deletes every case fact that install ever shared, not just future ones.
• Usage analytics — on by default. Same screen, its own switch. De-identified product-usage events only; the exact payload is listed under Optional, de-identified usage analytics.
• Crash reports — on by default. Same screen, its own switch. Scrubbed crash detail, nothing else.

Two more controls sit alongside them. Your iCloud Backup is your own, between your devices and your iCloud, and it is never paused by anything we do. And declining an updated Terms of Use pauses all four of the switches above at once — see If you decline updated terms. You can log cases, see your progress, and export everything with all four off.

Every category below has its own section further down with the detail. This is the whole list in one view: what it is, where it lives, and why we have it. Most of it never leaves your phone.

On your device, and nowhere else

• Your full case log, including the optional private note on a case. Encrypted on the device. This is the complete copy; what syncs is a de-identified subset of it.
• Your plans, your attending and specialty notes, your standalone notes and their images, and your templates. Encrypted on the device under keys that never leave it. These are the fields that can hold patient context, and they are the ones we cannot read.
• Your settings and local copies: your training year and program, your own name (so the app can find your rows on an OR board), your copy of the program roster, your saved surgeons and rooms, and drafts in progress.
• Voice entry: the audio buffer and its transcript exist only long enough to fill the form, then are discarded. No recording is kept and none is uploaded.

In your own iCloud, if you turn iCloud Backup on

• One encrypted backup of your cases, plans, and notes, so a lost phone is not a lost log. It is end-to-end encrypted under a key held only in your own iCloud Keychain — we are not a party to it, and no Capnolog server is in the middle.

On our servers

• Your account. An opaque account id; the ids of the devices linked to it; your training program, your specialty, and your class year; whether you hold a beta or early-access grant (an operational flag, not a fact about you); an audit record of changes made to the account; the ids of the events our sign-in provider sends us about it, so a repeated event is applied once; and — if you verify your program — evidence of that verification, and, while a verification code is outstanding, a one-way hash of the address it went to. Never your name, never your institutional email address, never a case. See Your Capnolog account below.
• A device identity. Separate from the account: a random id tied to a hardware key on the device — an Apple App Attest key on iPhone and Mac, a hardware-backed Android Keystore key on Android — plus that key and a counter, so we can tell a real Capnolog install from anything else talking to our servers. It names a device, never a person, and we have no way to turn it into your name.
• Your de-identified case log — the fields your CSV export carries, a random case ID, and whether each case has been filed. On by default so tracking works and the extension can pull your unfiled cases; off, and purged, whenever you want.
• De-identified case facts, if you turn research sharing on: taxonomy codes, the month (never the day) of a case, and per-resident ordinals standing in for site and attending. This is what feeds the anonymized statistics.
• Your ACGME import record, if you run the one-time history import: your own previously-filed cases mapped into Capnolog’s categories, the site and supervisor labels as they appear on the form, the ACGME case numbers you certify, and the certification itself. Held only so your phone can pull them into your log, and excluded from every statistic.
• Your program’s roster — the site and supervisor (attending) option lists as the ACGME form publishes them, with the program code and specialty, so every resident’s app can pick the option the ACGME expects.
• Extension pairing credentials and the one-time codes that create them, so your browser can read your own cases and nobody else’s.
• Consent receipts — which version of the Terms you accepted or declined, when, and from which surface.
• Diagnostics, and how a case was filed — enumerated codes, counts, timings, and the combination of ACGME codes a case was filed under, so a fill that breaks can be repaired and the app can stop making you reassemble the same bundle by hand.
• Crash reports — the error name, a short message run through a scrubber on your device before it is sent, a structured stack (function name, file name, line number), which screen you were on, and the app and OS version. There is no raw stack and nowhere for case content to ride along. When usage analytics is on as well, the error name and that structured stack also go to PostHog — never the message.
• Attending feedback answers — your weekly yes or no about whether you learned something from an attending, keyed by a letters-only digest of their name rather than the name itself, so the teaching signal can be pooled across a program.
• How long a case took to log — a number of seconds and a random per-case id. This is where the logging-speed number on our home page comes from.
• Which features you have used — the name of a feature the first time you use it (voice entry, templates, notes, plans, case lists, progress, export, schedule import, calculators), and nothing else: no count, no content, only the day our server received it. It exists so the tips mail after you create an account can skip what you already use. It is tied to your device record and, once you sign in, to your account, and it goes when they do.
• Study Lab relay data, if you use it: your study plan, coverage snapshots, the tag names from your own flashcard deck, execution reports, and review counts. Topic and card identifiers, never case data.
• A push notification token, if you turn on OR-board alerts — an Apple device token subscribed to a program code. The push itself carries no board content.
• The OR board, for programs whose department board Capnolog mirrors. We store the whole departmental board as the department publishes it — room, procedure text, time, anesthesia type, staff names, and the scheduler’s notes — because the server addresses a program and cannot know which room is anyone’s; your phone downloads the board and finds your own rows locally. It carries no patient name, MRN, or date of birth, and every board is scanned for anything patient-shaped before it is stored. The names on it are staff, not patients.
• The structure of the ACGME form — field names, ids, and option labels, never the values in them, so we can repair the fill when the ACGME changes its page.
• Which tier your install has, if you buy something or receive a grant, and where that entitlement came from.
• A program-verification request, if you are a medical student and send one: the display name you chose, the program and dates you entered, your counts — cases, procedures, clinic days, call shifts, and firsts — and, if you added them, your medical school, class year, and a short note. This is the one place the app sends your name to our servers. It goes only where you aimed it — residents at that program who use Capnolog — and it is deleted after 90 days, or sooner if you take it back. See Medical students below.
• Residents’ answers to those requests — a yes or no, an optional reason from a fixed list, and, after a yes, an optional short evaluation (rating scales, preset words, one line of text). Each is stored against the resident’s device identity and shown to the student as coming from a resident at that program, never with a name.
• Class-group membership, for medical students: which school-and-class-year group your device joined, when, and the random code of any class invite link you created.
• Invite links and redemptions — the random code of a link you created, with its program and specialty; and, if you installed through someone’s link, that your device redeemed it, when, and when your use of the app first counted as active for the person who shared it.
• Ambassador records, if you sign up: your program, class year, and program length, why you signed up (chosen from a short list), the class slot you claimed, the reward grant and milestones that came with it, and — only if you ever agree to be quoted — the quote and your consent to it.
• Evidence suggestions and corrections you send from the app: the text, link, and reason you typed, which topic or paper it was about, and your app version, held against your device identity while a person reviews it and until you ask us to remove it.
• Reliability events — when something in the service fails or goes stale (a roster poll that did not complete, a verification step that was refused), a record made only of codes from a fixed list, bounded numbers, and version strings, sometimes with your device identity and a one-way digest of an internal id. There is no free-text field in it at all.
• Beta, program, and updates signups — your email address and the answers that come with it: who you are (resident, fellow, or medical student), your specialty, your program or school, and how you heard about us; or, on the programs page, your program and your role there. See Third-party services below. These, the updates list described there, and the feedback board below are the only places we hold an email address, and each is kept where it cannot be joined to anything else.
• Feedback board — if you suggest an idea, vote, or comment on our ideas and roadmap board, your email address. It is used only so you can do those things and to tell you when an idea you suggested or voted for ships. It is never shown on the board and never added to a mailing list.
• A rate-limit counter, derived from an IP address. Requests that carry no device identity — the beta form on this website above all — are counted per connection so one connection cannot flood the service. The counter is keyed by a one-way hash of the IP address made with a secret key we hold; the address itself is not stored, and the counter is never joined to a case, a device, or a signup. Counters are deleted after 24 hours.
• Ordinary server logs, for running and debugging the service. Authorization headers, cookies, passwords, and device tokens are redacted before anything is written.

With our analytics provider, if usage analytics is on

• Which features you used, tagged with a random identifier that is neither your name nor the device identity above, plus your training year, your program code and name, and your app and OS version. Nothing else — see Optional usage analytics below.

On this website

• One entry in your browser’s local storage remembering which specialty page you last opened, one more remembering your answer to the cookie bar, and — while the tab is open — one holding the anonymous counting id. No advertising cookies and no cross-site trackers, ever; an ordinary cookie only if you press Accept on the bar — see Cookies and local storage below.
• Anonymous page-and-click counts, so we can see which parts of the site help and which lose people: which page was viewed, how far down it was scrolled, which section of the page you reached and for how long, which button was pressed, and how far into the signup form people get. No name, no email, no IP address, and nothing you type — see What the website itself measures below.

Using Capnolog requires one free account — residents, fellows, and medical students alike. You sign in once, and the same account is what lets a second device, a new phone, the Mac companion, or the browser extension be recognised as yours. It is free and it stays free: logging and export never cost anything, and the account is what the app asks of you, not a payment. If your phone cannot reach us — no signal, or our sign-in provider is having a bad morning — the app keeps working and asks again when it can, because a case you are trying to log is not something we are willing to hold hostage to our own uptime.

How you sign in. Sign in with Apple, or a personal email address. Use a personal address, not your institutional one: your hospital or university mailbox is not the right place for this, and we do not want it. Sign-in itself is handled by Clerk, a US authentication provider acting as our processor; they hold the credential — the email address or Apple relay address you sign in with, and any name Apple chooses to share — and we hold only the opaque user id they give us. Their handling is listed alongside our other processors under Third-party services.

What the account holds. An opaque account id; the ids of the devices you have linked to it; your training program, your specialty, and your class year; whether you hold a beta or early-access grant; and, if you verified your program, the evidence of that verification. That evidence is deliberately partial: for an institution-email code we keep a one-way HMAC of the address and the email domain, never the address itself, so we can prove the check happened and cannot read who took it. We also keep an audit record of the changes made to the account — what changed, and when — so a dispute about your program or your access has an answer.

Why specialty, class year, and the beta flag. Your specialty and class year are the same two facts the app already needs to grade your progress against the right ACGME requirements; the account holds them so a second device gets the right answer without asking you again. The beta or early-access grant is an operational switch that decides which features your account can reach. None of the three narrows you to a person on their own, and we hold no name to combine them with.

What the account never holds. Your name — the account never holds it. The app asks for your name only for screens that stay on your device and, if you are a medical student, for a program-verification request, which travels on its own and is described under Medical students below. Your institutional email address — where you verify by institution email we keep only the one-way HMAC and the domain described above; the code itself is delivered by the email provider named under Third-party services. Your cases — the case log stays on your phone, and the de-identified subset that syncs is keyed to your device identity, not to your account. Nothing about a patient, ever. The one identifier that exists is held by Clerk, not by us: the email or Apple relay address you sign in with, and any name Apple chooses to share with them.

Where a name can and cannot exist, in four places. “We do not hold your name” is a claim worth breaking apart, because four different systems are involved and they do not behave the same way.

• Our application database — does not intentionally store your name. The one exception is a medical student’s program-verification request, which carries the display name you chose and is described under Medical students; it is the one place the app sends your name to our servers, it happens only when you tap send, and you can take it back.
• Our authentication provider (Clerk) — does hold sign-in identifiers: the email address or Apple relay address you sign in with, and any name Apple chooses to supply with a Sign in with Apple credential. We receive an opaque id from them and not the address.
• Waitlist and support mail — holds whatever you put in it: the email address you wrote from or gave us, and the text of what you wrote, which may include your name because you signed it. That is a mailbox, not a database, and it is kept apart from everything above.
• Analytics — holds no name at all. What it carries is a random identifier plus cohort attributes (training year, program, app and OS version), and we call that de-identified rather than anonymous for the reason given in its own section.

When you write to us for help. Often the only thing connecting your message to your account is the address you signed in with — which Clerk holds and we do not. So when answering you requires it, we can ask Clerk for the sign-in email on a single account. Every such lookup writes an audit record of which account was looked up, when, and why. The address is read and used to answer you; it is never copied into our database, and it is never added to a mailing list. Being able to look an address up is a different thing from holding it, and we still never store your name or your institutional email address.

Linking and unlinking. Linking a device adds its id to your account so your progress and your extension see the same log. Unlinking removes that one device’s link and nothing else: the account stays, your other devices stay, and the cases on the unlinked device stay on it.

Your program, once verified. Verifying pins your training program to the account, and it stops being a free-text field you can edit — a verified program is a claim someone else relied on. If you move programs, or we got it wrong, write to us and we will change it.

Deleting it. Delete the account from Settings, at any time, for any reason. It removes the account record — the account id, your training program, specialty and class year, and any beta grant — along with the linked device ids and the verification evidence. Deletion is idempotent — asking twice is not an error. It does not touch the cases on your phone, and it does not delete your consent receipts, which we keep for the reason given under Consent records.

Every case you log is stored in an encrypted database on your phone, on iPhone and on Android alike. The database file is encrypted at rest, so it cannot be read off a lost, stolen, or imaged device without your key. Where the app locks itself, it uses Face ID on iPhone and your fingerprint or face unlock on Android; the biometric is checked by the operating system and we never receive it.

iCloud Backup is an optional feature on iPhone, so a lost or replaced phone never means lost data. When it’s on, Capnolog keeps an encrypted backup of your full log in your own private iCloud through Apple’s CloudKit — per Apple ID, with no Capnolog server in the middle. The backup is end-to-end encrypted under a key that lives only in your iCloud Keychain and never leaves your own devices, so the cloud copy is unreadable to anyone but you — not Apple, not us. Your data only ever moves between your own devices and your own iCloud. On a new device, you restore everything with one tap.

Backup on Android works differently, because there is no iCloud to write to. You pick a folder on the device (or in whatever storage provider you have set up) and you set a passphrase. Capnolog writes an encrypted backup file into that folder, encrypted under your passphrase and nothing else. The passphrase is the key: it is not stored on our servers, we never see it, and we cannot reset it or recover the file for you. Anyone who has both the file and the passphrase can read the backup, so keep the folder somewhere you are willing to keep a copy of your log. To restore on a new Android phone you point the app at the file and enter the passphrase. As on iPhone, the backup never goes to us.

One qualification, because durability is the thing people rely on most. All of that describes how Capnolog is built — it is not a promise that nothing can go wrong. On iPhone the backup depends on your iCloud account and on Apple, both outside our control, and a restore can be incomplete when iCloud is unavailable, when the account is out of space, or when the most recent changes had not been backed up yet. On Android it depends on the folder you chose staying where you put it and on you still having the passphrase: a folder you delete, a provider you sign out of, or a forgotten passphrase leaves a file nobody can read, us included. Keep your own exports of anything you cannot afford to lose.

The backup covers everything needed to make you whole — your cases, and the private plans and attending notes you keep (see below). You can turn it off in Settings, and the first time you turn it on we ask you to confirm, since those plans and notes can contain patient context. On iPhone, erasing all data also deletes the iCloud backup; because the key is shared across your devices, that erase removes the backup on your other devices too. On Android, erasing all data deletes the backup file in your backup folder and forgets your backup passphrase on this phone; if the folder cannot be reached, the app keeps retrying until it is done. A copy you moved or synced elsewhere is outside the app, and only you can delete it.

Capnolog keeps a lightweight, de-identified copy of your case log in sync through our zero-PHI backend, so you can see whether a case has been filed with the ACGME from any of your devices in real time, and so the browser extension can pull your unfiled cases directly instead of you exporting and pasting a CSV. What we receive is exactly the fields your CSV export carries — case type, dates, and role — plus a random case ID and whether it’s been filed. It never includes an MRN, a name, a date of birth, or any other patient identifier, and your private note never leaves your device under any circumstance. Every upload is checked against a structural filter that blocks anything shaped like patient data before it’s accepted.

This sync is on by default so tracking works the moment you install the app, and Capnolog tells you so once, the first time the app is usable. That notice carries the Turn off button, and the same switch lives at Settings → Data, backup & export. Either one turns it off, and turning it off deletes your case data from our servers immediately and reverts you to on-device-only; the Log tab carries a reminder banner while sync is off. With sync off, the browser extension can’t pull your cases — you can still export your case log as a CSV for your own records or to enter into ACGME by hand.

Capnolog turns de-identified case logs into anonymized, aggregated statistics: averages, distributions, and trends across many residents, such as typical case counts by training year, program-level case mix, or national pacing. These statistics may be analyzed, displayed, published, and shared with third parties, including residency and fellowship programs, medical students and residency applicants, researchers, and the public, and they help improve Capnolog itself, including its study and progress tools.

What goes in is already de-identified: the same fields described under De-identified case sync, and, as study features arrive, de-identified study activity such as topics reviewed. Never your private note or plans, which we cannot read. Cases imported from your ACGME record by the browser extension are excluded — the statistics are built only from cases you logged in Capnolog, and only from what you shared while research sharing was on. What comes out carries no name and no case ID. Nothing that identifies you is ever shown to your program or anyone else unless you explicitly choose to share it yourself. Today the one such feature is a medical student’s program-verification request, described under Medical students below: it sends what the screen shows you, when you tap send, and nothing else.

What “anonymized” means here, and what it does not. Before anything is published we apply safeguards designed to reduce the risk of re-identification: aggregation, suppression of small groups, and removal of direct identifiers. Concretely, the public statistics we publish today are withheld entirely unless at least 25 trainees stand behind them; nothing about a single program is shown until a minimum number of that program’s trainees have shared; and a person reviews a report before it is released. What we will not tell you is that this is risk-free. No de-identification method can guarantee zero risk in every circumstance, and a page that claimed otherwise would be worth less to you than this sentence.

Programs. A program can sign in — that changed in September 2026, and it is worth being exact about what it means. The Program Console gives a small number of named people at a program (a chief resident, a program director, a coordinator, or an attending the department designates) a sign-in of their own. Each one is invited and confirmed individually, agrees to the Terms of Use in their own name, and can be revoked. What a signed-in program administrator can see is the department’s own material and program-level totals: the roster and OR board as the department publishes them, which carry staff and resident display names, room assignments and scheduler notes and never patients; the schedules they publish themselves; and aggregate counts built under the safeguards above. What the console has no route to is your log. A program administrator cannot open your case log, cannot see your individual cases, cannot identify you from aggregate reporting, and gains no ownership of the log you created. If we ever build identifiable reporting to programs it will be a separate feature with its own consent and its own update to the Terms of Use before it ships.

You agree to this when you accept the in-app agreement on first launch. When you accept, Capnolog records the version you agreed to and when, under the same de-identified sync identity described above, as the receipt of that agreement. Aggregated statistics that no longer identify you may be retained after you delete your data; everything identifiable follows the deletion and purge rules described on this page.

A program administrator’s sign-in creates records of its own, on our servers, about them rather than about you. They are listed here in full, with what each one is for, who can see it, and how long it lives. None of them contains a case log, a private note, or a plan, and none of them appears in a resident’s export or in a resident’s device backup.

• The administrator’s binding to the program — their role (chief resident, program director, coordinator, attending, or other), the opaque id our sign-in provider gives us, a one-way hash of the email address they were invited at, the display name they choose once signed in, and whether the binding is pending, active, or revoked. Why: it is what decides whether a request is allowed to touch that program’s data at all. Who sees it: that person, the other administrators of the same program, and us. How long: while it is active; a revoked binding is kept for 400 days and then deleted. Schedules that person published stay published — the authorship is dropped, not the schedule.
• Their agreement to the Terms of Use — which version they accepted, when, and for which program. A person who administers two programs accepts once for each, because the two are separate responsibilities. Why: it is the receipt that they agreed before touching a roster. Who sees it: us. How long: with the binding, and it survives revocation for the same 400 days — a receipt deleted on request is not a receipt.
• Access requests and invitations — when someone asks for console access, or is invited to it, we hold their email address in the clear, their name, and the program they typed, until the request is decided. This is the one place in Capnolog that stores a readable email address, and it is deliberate: there is no way to write back to someone about access without it. Why: to reach them, and to tell one request from another. Who sees it: us, and the administrators of the program being asked about. How long: deleted 90 days after the request is approved or denied; a request nobody ever decides is deleted 90 days after it was made.
• Unpublished schedule drafts — a work-in-progress schedule, carrying staff and resident display names, room names, and whatever the scheduler typed in the notes. Never patients. Why: so a schedule can be built over several sittings. Who sees it: the administrators of that program, and us. How long: a draft expires 7 days after it is started and is deleted 7 days after that.
• Published schedule versions and snapshots — the same material, once published, plus the earlier versions of it, so a change can be seen and undone. Why: it is what the OR board in the app reads. Who sees it: that program’s administrators and the residents at that program, and us. How long: while the program’s console is in use, and for 90 days after the program’s console data is terminated, after which they are deleted.
• Sign-in tickets and device records — the short-lived codes that carry a sign-in from a phone to a browser, and a record of which devices and sessions an administrator has signed in from. Why: to complete a sign-in, and to let an administrator end a session they no longer recognise. Who sees it: that administrator, and us. How long: a ticket is deleted 24 hours after it expires; a device record is deleted 30 days after it is revoked.
• Audit events — who signed in, who invited or revoked whom, and what was published, with the opaque id of the person who did it. Why: a console that can change a department’s schedule has to be able to say who changed it. Who sees it: us, and a program’s administrators for their own program. How long: 400 days. Audit records are the one thing here that outlives the account they describe, for the reason given under How long we keep things.

If a program stops using the console. Every binding is revoked at once, and the drafts, sign-in tickets, device records and undecided access requests are deleted at once. Published versions and snapshots are deleted after 90 days, so a department that changes its mind inside a quarter does not lose its own schedule history. Audit events are kept for their 400 days. Nothing about a resident is affected by any of it: their case log was never in these tables.

Logs and backups. These records sit in the same database as the rest of the service and are covered by the same encrypted backups and the same server-log rules described under How we protect it. Server logs record that a console request happened and by which opaque id, never the contents of a schedule.

Microphone & Speech — only when you choose voice entry. Speech is transcribed on-device; the audio buffer is used for transcription and then discarded. No recording is kept, and no audio or transcript ever leaves the phone. The parse runs fully on-device on every supported iPhone.

Face ID / passcode — used to lock the app so case data isn’t visible if someone else picks up your phone. The biometric check happens entirely on your device; we never receive it.

Five companies are in the path, and no others. For each one: what it is for, what it receives, where it processes it, and where its own policy lives.

Apple iCloud — when iCloud Backup is on, your own private iCloud is the only place your full case log — the complete copy, with your private note — is stored off-device. It rides end-to-end encrypted under a key only your devices hold, and we are not a party to it. The de-identified subset described under De-identified case sync is a separate thing and does reach our own servers. Where it is processed follows your Apple ID’s region rather than anything we choose, and it lasts until you erase it or turn the backup off. Apple’s policy: apple.com/legal/privacy.

Sign-in (Clerk) — the free account described under Your Capnolog account signs in through Clerk, a US authentication provider acting as our processor. They handle Sign in with Apple and email sign-in and hold the credential that goes with it — the email address or Apple relay address you use, and any name Apple chooses to share with them; we receive an opaque user id and never see a password. That address is the one identifier in this system that we deliberately do not hold. We do not send them your cases, your program, your specialty, your class year, or anything about a patient. Clerk processes it in the United States, holds it for as long as your account exists, and deletes the hosted user when you delete your account — that is the second half of the delete described under Deleting your data, and the app keeps retrying it until it settles. Clerk’s policy: clerk.com/legal/privacy.

Email delivery (Resend) — when you verify your program by institution email, the one-time code is sent through Resend, a US email-delivery provider acting as our processor. They handle the address and the code in order to deliver it, and nothing else: we keep a keyed one-way hash of the address and its domain, never the address, and Resend receives no case, no program, and nothing about a patient. What goes through Resend is this: the institution-email verification code; the follow-up we send after a signup on this site or a new account in the app; a short series of getting-started and tips mail in the weeks after an account is created; a purchase receipt and a renewal notice if you subscribe; a note when an idea you suggested or voted for on the feedback board ships; and the occasional updates mail to people who kept the box ticked. Not support replies, and not notification mail. The receipt, the renewal notice and the verification code are sent whatever your update settings say, because each one is about something you did or bought. The tips mail and the updates mail are not: every one of them carries an unsubscribe link in its footer, and it stops those mails and nothing else. One more mail exists and never reaches you, a daily operations summary the founder receives, and it contains counts and no addresses. Resend processes them in the United States and keeps its own delivery logs under its own policy. For the verification code we hold none of the address to delete; for a signup, the address is the one you gave us, described below. Resend’s policy: resend.com/legal/privacy-policy.

Analytics (PostHog) — when usage analytics is on, de-identified product-usage events go to PostHog so we can see which features help most. It is on by default and has its own switch in Settings. What it receives is the whole payload listed under Optional, de-identified usage analytics: which features were used, a random identifier, your training year, your program, and your app and OS version. No patient data, no name, no case content, no case ID. If crash reporting is on too, PostHog also receives each crash’s error name and structured stack (function name, file name, line number), never its message. We send it to PostHog’s US host, and IP-based location lookup is switched off at the provider, so your address is never turned into a place. Our own backend sends PostHog nothing, so there is no second, server-side path you cannot switch off. This website counts its own page views and clicks through the same provider, but as a completely separate, anonymous lane that is never joined to your account, and one you answer for yourself in the cookie bar at the bottom of the page — all of it is listed under What the website itself measures. PostHog’s policy: posthog.com/privacy.

Android purchases (Google Play) — this one is in the path only if you buy something on Android. Google Play takes the payment: we never see a card, and no payment detail of yours reaches our servers. Your phone hands us the opaque purchase token Google gave it, and our server asks Google what that token means. That request carries two things and no others — the app’s package name and the token itself — and it is authorized by our own service-account key, not by anything of yours. Google answers with the subscription’s state, its start and expiry, the product and plan bought, Google’s own order id, and whether it renews; when the subscription later changes, Google pushes us the same kind of update through Google Cloud Pub/Sub — a message id, what changed, the purchase token, the product, and when it happened. We keep those notifications so that a repeated one is applied once, and we keep one entitlement record: the purchase token, the tier it grants, when it runs out, Google’s order id, and the product name, price, and currency your own store showed you, so that you can produce a receipt. Google receives no name, no program, no case, and nothing about a patient — there is no field in that request for one. Google processes it on its own infrastructure under its own policy; we call one endpoint and choose no region. Google’s policy: policies.google.com/privacy.

Beta, program, and updates signups (this website) — these are not a third party. Both forms on this site post straight to our own server and land in our own database; no form provider and no marketing platform is in the path. The one thing that leaves our server is the mail itself, which goes through Resend as described above.

The beta form first asks who you are. A resident gives an email address, a specialty, a program chosen from the ACGME directory (or “my program isn’t listed”, with the name typed if you like), and how you heard about us. A fellow gives the specialty, the fellowship, and the program as typed. A medical student gives a year, a medical school, and the specialty they intend to apply to (or “undecided”). The programs page has its own form for program leadership: an email address, the specialty, the program, your role there, and how you heard about us. We also record which form it came from and when. A typed school or program name is scanned for anything shaped like an identifier before it is stored, and refused if one is found.

Each form sends one follow-up email about what you asked for. Each also has a box, ticked by default, that reads “send me occasional Capnolog updates”: leave it ticked and the address goes on our own updates list, in our own database; untick it and the address goes nowhere but the signup itself. Every updates mail carries a one-click unsubscribe, and an address that unsubscribes is kept only as a do-not-mail record. Creating an account in the app also sends a welcome email and adds that address to the same list, with the same unsubscribe link in that first mail.

We will not pretend this is anonymous: an email address plus a named program can point at a person. So the signup is deliberately kept in a table of its own with no link to any device, case, roster, or statistic — there is no column that could tie it to one, on purpose. It is used to email you about the beta and to decide build order, nothing else. No patient data is ever in scope here. Ask us at privacy@capnolog.com and we will delete it.

The website loads no fonts, pixels, or embeds from anyone else, and its anonymous usage counting is bundled into our own code and served from capnolog.com. There is exactly one exception, and only if you ask for it: pressing Accept on the cookie bar loads one script from PostHog’s own servers — the session-replay recorder — because a replay cannot be made without it. Decline, or simply ignore the bar, and nothing is fetched from anywhere but capnolog.com. What it sends, and what it never sends, is listed under What the website itself measures.

If the company changes hands. If Chockstone Labs LLC, the Capnolog product, or substantially all of its assets are sold, merged, reorganized, or acquired, the data listed on this page may be transferred to the successor as part of that transaction. The successor takes it under this policy and the Terms of Use in force at the time and may not use it for a new purpose without asking you first; we will tell you in the app or by email before or promptly after the transfer. We do not sell personal information, and a change of owner is not a sale of it.

A case can carry one optional private note. It is field-encrypted with its own key; when iCloud Backup is on it stays end-to-end encrypted across your own devices, so its plaintext is never visible to Apple or to us. It is never sent to the ACGME and never included in any CSV export. The note editor reminds you not to enter patient identifiers.

Beyond the case log, Capnolog has two private, free-text features you control: a night-before plan for a case, and the notes you keep on each attending. These are yours to use however helps — so they can contain patient context if you put it there.

They live encrypted on your device, separate from the de-identified case log, and they are never sent to the ACGME, never in any CSV export, and never in a file you share with a colleague. They leave your phone only inside your end-to-end-encrypted iCloud Backup, when you turn it on — readable only on your own devices.

Capnolog lets you hand your case templates and the notes you keep on each attending — including any per-specialty preference notes — to a co-resident. It’s shared as a single file you send yourself, for example over AirDrop.

That file carries your templates and notes only. It holds no roster, no logged cases, no plans, and no patient identifiers — there is no field in it for them. Attending and preference notes are the free-text part, so before they’re shared, record numbers and date patterns are stripped automatically and you review exactly what’s included first. Whoever imports it picks which parts to accept, and Capnolog de-dupes against what they already have.

Capnolog also works for medical students, and almost all of what a student records stays on the phone. The rotation log, the season notebook — interviews, the people you meet, letters, wrap-ups, a rank-list draft — and the ERAS summary built from your own counts live in the same encrypted on-device database and the same end-to-end-encrypted iCloud backup as a resident’s cases. The notebook can hold other people’s names; that is what it is for, and it is why we cannot read it and never receive it.

Program verification is the exception, and the app says so on the screen before you send. If you ask the residents at a program to confirm that you rotated there, the app sends to our server the display name you chose, the program and dates you entered, your counts — cases, procedures, clinic days, call shifts, and firsts — and, if you added them, your medical school, class year, and a short note. Residents at that program who use Capnolog can see it; nobody else can, and nothing from your case log travels with it. The request is deleted 90 days after you send it. You can take it back earlier under Settings → Program verification, which deletes the request and every answer to it from our server.

Residents’ answers. A resident who sees your request can answer yes or no, with an optional reason from a fixed list. One who answers yes may leave a short evaluation — a few rating scales, a handful of preset words, and one line of text. Before it is accepted, every evaluation is screened for anything patient-shaped and for abusive terms; the resident can edit it for 24 hours and it is frozen after that. It is stored against the resident’s device identity and shown to you as coming from a resident at that program, never with a name or a year. The app keeps a copy of each evaluation you received in your own on-device records, and you choose whether it appears in your ERAS summary. On the server, an evaluation lives and dies with the request: delete the request and it is gone.

Class groups. Joining your school’s class group sends your school and class year, nothing else — no name. What the group shows is how many classmates have joined. A class invite link carries a random code, not your identity, and whoever created it can revoke it.

Program verification and class groups are each switched on by us per release, and the app offers neither until it is on; while one is off, nothing in this section about it is sent. Everything a student records stays under the same export, erase, and backup controls as a resident’s log.

Capnolog offers an optional Chrome extension that prefills the ACGME anesthesiology Case Log form (the only specialty it covers today). It works only inside your own ACGME account, in your own browser, at your direction. If case sync is on (the default), the extension pulls your unfiled cases directly using a one-time pairing token you generate in the app — the same de-identified fields described in De-identified case sync above, never your private note. With case sync off, the extension has no way to pull your cases — it works only when case sync is on. (You can still export your case log as a CSV from the app for your own records or to enter into ACGME by hand.) The form fill happens on your computer, the extension never presses Submit or any other save control, and you review and submit every case yourself.

The extension is not approved, authorized, or endorsed by the ACGME. We built it and we maintain it, and we have no arrangement with them about it.

We can pause it remotely. The extension checks a configuration we control roughly once an hour, so a pause we publish reaches every install within about that long — all of them, not a rollout — whether or not anyone updates. It lifts on its own when the reason for it expires, and an install that is offline keeps honoring the last pause it saw. A pause stops the extension from acting; it never deletes or alters your data.

What leaves your browser

• The de-identified case entries you chose to sync, and the fact that a case has been filed — the same fields listed under De-identified case sync, never your private note.
• If you run the one-time history import, your own previously-logged ACGME case entries — de-identified into Capnolog’s categories (case type, ASA class, age band and similar), the site and supervisor labels as they appear on the form, and the ACGME case number you certify — are uploaded to our server for one purpose: so your phone can pull them into your log. They contain no patient information, are kept only as your import record, are excluded from every statistic, and you can remove every imported case from your log in the app. How long we keep it: the import record on our side has no expiry and no delete button today — it is kept for as long as the Service runs, or until you ask us to remove it, and it is excluded from every statistic for its whole life. See Deleting your data below for the email path that reaches it.
• Your program’s Site and Supervisor (attending) option lists as shown on the form, so the fill can pick the exact option the ACGME expects. Those lists contain no patient information. When two residents independently report the same entries, they become part of the shared program roster — so everyone’s app stays current without anyone emailing a setup file around.
• While the extension is paired, its reading of the form structure: field names, ids, and option labels, never the values in them, so we can repair the fill the day the ACGME changes its page. Agreeing to the Terms of Use covers this; the extension does not ask separately. How long we keep it: until it is replaced by a newer reading of the same form. It describes the ACGME’s page rather than you, and only the current one is of any use.
• Zero-PHI diagnostics: counts, timings, and halt codes that say where a fill stopped, and extension health events — pairing steps, sync outcomes, and sanitized error reports with any long digit runs masked. Fill diagnostics go to our server and are mirrored to PostHog, our US-hosted analytics provider (its policy is linked under Analytics above); health events go to PostHog only. Everything carries a random install identifier that is not linked to your name, email, or account, and your specialty and your program code travel with it, so a broken fill can be traced to the form it broke on. We instruct PostHog not to record the IP address these events arrive from and not to derive a location from it. These diagnostics are separate from the app’s usage-analytics switch and are on whenever the extension is installed. No case content, no page text, no patient information.
• Consent receipts — see Consent records below.

What never leaves your browser

• Your ACGME username, password, cookies, or session. We never receive them, we never store them, and we cannot sign in as you.
• Any other page content. Nothing beyond the items listed above is read or sent — not the rest of the ACGME page, not anything else you have open. The extension runs on the ACGME Case Log site only, keeps no browsing history, and reads no other pages.

What we do with it. Anything read from the ACGME is used for exactly one purpose: keeping your Capnolog log accurate — matching entries to what you already logged, preventing duplicates, setting your starting counts, and picking the right option on the form. It is never used for statistics, research, or product analytics, and cases imported from your ACGME record are excluded from the anonymized statistics described above and from any research sharing you opt into.

After you file a case, the extension reports back that it’s been logged — so your case list shows “filed” on every device — and, in your browser, stores only a pairing credential and small sync bookkeeping (a hash and timestamp of the last-sent roster lists, and the IDs of cases already filled, so it never re-pairs or double-enters a case).

When you accept — or decline — the Terms of Use, Capnolog writes a single append-only receipt: the version of the terms, the decision, the time it was made, and which surface it came from (the app or the browser extension). Nothing else is in it.

The receipt is tied to your device identity — the same de-identified identity the case sync uses — never to your name, and never to a patient. Receipts are only ever added, never rewritten, so the history of what you agreed to stays intact. They exist so both of us can show what was agreed and when; they are not used for statistics, analytics, or advertising.

When the terms change materially, Capnolog asks you to accept them again. If you decline, the app does not lock you out and it does not delete anything. Everything that happens on your own device keeps working: logging cases, your plans and notes, progress, and study.

What pauses is the lanes that carry your data off the phone — de-identified case sync, the browser extension, sharing for research, and usage analytics — until you accept. We call that limited mode. Case sync, research sharing, the extension, study, the OR board, push registration, attending feedback, crash reports, and analytics all stop. A short list keeps working, because holding it would leave you stuck rather than protected: the app can still prove it is a real install, upload the receipt that records your decline, check whether the build is too old to run, read your program’s directory entry, and confirm a tier you already paid for. Nothing on that list carries a case. Your iCloud Backup is never paused by a declined version, because it runs between your own devices and your own iCloud and needs nothing from us. You can accept later in Settings, and what paused resumes; you can also export or erase your data at any time either way.

To help us decide what to build next, Capnolog can send de-identified usage analytics to our analytics provider: which features you used, and when. Three things ride along with each event — a random identifier the app generates for itself (not your name, and not the device identity the case sync uses), your training year, and your program, plus your app and OS version. That is the whole payload.

We call it de-identified rather than anonymous, and the difference is deliberate. It carries nothing that names you, but a training year and a program together can narrow to a small group of people — at a small program, sometimes to one. Calling that “anonymous” would be claiming more than we can deliver, so we don’t.

What it never includes: patient details, your name, your case fields, a case ID, your private note, or your plans and notes. There is no cross-app tracking, no advertising identifier, no session recording or screenshotting, and no location lookup — location is switched off at the provider, so your IP is not turned into a place.

Analytics is on by default so we can see what’s working, and you can turn it off at any time in Settings → Data & privacy → Research sharing & analytics. It stops from that moment. Three other things also stop it: declining updated terms pauses it along with everything else that reaches the network, erasing all data in Settings discards the random identifier so the history cannot be continued, and deleting the app ends it. Turning it off is a switch, not a request — nothing to email, nothing to wait for.

Crash reporting is a separate lane on the same footing: on by default, its own switch on the same Settings screen, and it sends only the scrubbed crash detail listed in What we collect, in one place. It pauses in limited mode along with everything else.

This website itself runs no advertising pixels, no Google Analytics, and no cross-site trackers. What it does measure is set out in What the website itself measures next: a separate, anonymous lane with no switch, because there is nothing of yours in it to switch off.

Separately from the app, capnolog.com counts how the site is used, so we can see which parts help and which lose people. It is anonymous, and the whole list of what it sends is short: which page you viewed (as a route, like /pricing), the host of the page that linked you here and the utm_source tag if the link carried one, how far down a page you scrolled, which sections of the page came into view and roughly how many seconds each one held you, which named button or navigation item you pressed and where on the page it sat, which FAQ questions you opened, how long the page took before your first tap or scroll, how far down you had got when you left, how far into the signup form you got and which of its fields you reached — by field name, never its contents — and, if a submission fails, the reason code for that failure. It also records your browser’s own page-speed measurements and a coarse device type (desktop, mobile or tablet). If a script on the page fails, it sends the error’s type, its message with any quoted text, email address or long number taken out, and which of our files, functions and lines it came from.

What it does not send: your name, your email, anything you type into a field, the address behind an email link you click (only that it was an email link), your IP address, or any location derived from it. Nothing that identifies you personally is in the payload, and none of it is joined to your Capnolog account or to anything in the app. We never call the provider’s identify step, so no profile of you is ever created.

You choose how it remembers you, in a bar at the bottom of the page. Until you answer — and permanently, if you press Decline — the counting is cookieless: no cookie is set, and the anonymous identifier lives in this tab’s session storage, which is gone when you close the tab and cannot be read by any other site, tab or later visit. There is no session recording, no heatmap, and nothing at all is loaded from the provider’s servers.

If you press Accept, three things change and nothing else does. One ordinary cookie and one local-storage entry hold the same anonymous identifier so a return visit is recognizable as the same anonymous visitor. A session replay is recorded — a reconstruction of scrolling and clicking in which every field’s contents and all page text are masked before anything leaves your browser, and the beta signup card is blocked out entirely rather than recorded. And click and scroll heatmaps are collected. Making a replay needs one script from the provider’s own servers, so accepting is also the only circumstance in which this site loads a script from anywhere but capnolog.com.

Your answer is kept in one local-storage entry named capnolog_consent — the word “granted” or “denied” and the date — and it never leaves your browser. You can change it whenever you like: the Cookie choices link in the site footer reopens the same bar, and clearing your site data resets it.

It goes to the same provider the app uses, PostHog, on its US host, with IP recording and location lookup switched off on every single event. The counting code itself is bundled into the site and served from capnolog.com.

If your browser sends Do Not Track or Global Privacy Control, none of this runs at all. We check before we start, and with either signal set the counting code is never even downloaded and the cookie bar is never shown — no event, no request, nothing.

capnolog.com sets no advertising cookies and no cross-site trackers, in any circumstances. No Google Analytics, no ad pixels, no social embeds, and no third-party font or embed — so nobody else is ever in a position to set a cookie while you read.

There is exactly one cookie on this site, and you decide whether it exists. The bar at the bottom of the page asks once. Until you answer, and permanently if you press Decline, the anonymous usage counting described in What the website itself measures sets no cookie at all: it keeps its random identifier in this tab’s session storage, which is emptied the moment the tab closes. Press Accept and the same identifier moves into one first-party cookie and one local-storage entry, so a second visit is recognizable as the same anonymous visitor. That is the whole of it — the cookie holds a random id, it belongs to capnolog.com alone, no other site can read it, and it is not used for advertising in any form.

What the site stores in your browser’s local storage is short and readable: which specialty page you last opened, so the site can pick up where you left off (a label like anesthesia), and your answer to the cookie bar under capnolog_consent. Neither ever leaves your browser, and clearing your site data removes both. If your browser blocks storage, the site simply forgets — nothing else changes.

You can change your answer at any time from the Cookie choices link in the site footer, which reopens the same bar. Declining after accepting stops the recording and puts the counting back on the cookieless setting.

The signup forms on this site post to our own server, so no form provider sets a cookie either — see Third-party services above for exactly what that form sends and why.

In the apps, storage is ordinary app storage on your own device: the encrypted database, your keys, and your settings. There is no cross-app tracking, we do not use the advertising identifier, and we do not ask for tracking permission because we have nothing to do with it.

Global Privacy Control and Do Not Track — we honor them by not doing the thing they object to. There is no targeted advertising, no sale of personal information, and no cross-context behavioral advertising here to switch off, so a GPC or DNT signal finds nothing of that kind to stop. It does stop one thing outright: the anonymous usage counting described in What the website itself measures is skipped entirely when either signal is set — we check before starting, so the code is never even downloaded.

Some of what the app does is automated, and this is the whole list. Speech recognition and the parser that turns what you say or type into a structured case run on your phone, and the words never reach a server. The study scheduler picks what to show you next from your own activity, on the device. Progress projections are arithmetic over your counts and published requirements. On our servers, the writes that carry de-identified case data are re-scanned by rules that look for anything shaped like patient data, and a submission you send us is screened for the same before a person reads it.

None of it sends your words, your cases, or your notes to an outside artificial-intelligence provider. As of this version no such provider is in the path, and the five companies under Third-party services are the only ones that are. If we ever add a feature that hands your data to one, that company will be named on this page before the feature ships, and where the change is material you will be asked to agree to updated terms first.

No decision that has a legal or similarly significant effect on you is made solely by an automated system. Automated output can be wrong: a parsed case is shown to you for review before it is saved, and a projection or study suggestion is a planning aid you can ignore. The de-identified case data and the corrections you make while reviewing a parse are used to improve the parsers and study tools, under the switches described in the Terms of Use, section 6.

On your phone, the whole database is encrypted at rest and can be locked behind Face ID, so a lost or stolen device does not give up your log. On top of that, the fields that can hold patient context — your private note, your plans, and your attending and specialty notes — are encrypted a second time, each under its own key, and those keys are held on the device and never sent to us.

Your iCloud Backup is end-to-end encrypted: each backup gets its own key, that key is sealed under a master key that lives only in your iCloud Keychain, and only your own devices ever hold it. We never have it, and neither does Apple.

Everything in transit is encrypted. Every lane that carries anything of yours requires an install that can prove, using the device’s own hardware attestation — Apple App Attest on iPhone and Mac, a hardware-backed Keystore key on Android — that it is a genuine Capnolog app on a genuine device, so a scraper with a stolen URL gets nowhere. A handful of routes are deliberately open, because they have to be: the public statistics on our home page, the ACGME program directory, the check for whether your app is too old to run, and the beta form on this site. None of them reads anything of yours.

Writes that carry your data are rebuilt field by field from an allowlist rather than stored as they arrived, and re-scanned for anything shaped like patient data before they land. Passwords, tokens, cookies, and authorization headers are stripped from our logs.

No system is perfectly secure, and we will not tell you otherwise. If a breach affects your data, we will notify affected users and the regulators the law requires us to notify, in the time the law requires — for an Ohio company that is the Ohio breach-notification statute (R.C. 1349.19), which sets a 45-day outer limit, and the law of the state you live in where it is stricter. We keep a written information-security policy that names the control behind each claim on this page, so that promise is backed by a document rather than a sentence.

Reporting a vulnerability. If you find a security problem in the apps, the extension, or this site, email support@capnolog.com with “Security report” in the subject, or read /.well-known/security.txt. We acknowledge within 2 business days, triage within 24 hours of confirming a real issue, and will not pursue a good-faith researcher who stays within their own accounts and data, avoids privacy violations and service disruption, and gives us a reasonable time to fix before disclosing. Please do not test against other users, and never include patient information in a report.

Where we can give you a number, here it is. Where the honest answer is “until you delete it,” we say that instead of inventing a schedule.

• Everything on your device, and your iCloud Backup — until you erase it, or delete the app. We have no clock on your phone.
• Your de-identified case log — until case sync is turned off, which purges it, or until you ask us to purge it. Otherwise for as long as you use the Service.
• De-identified case facts — until you turn research sharing off, which purges everything that install ever published.
• Extension diagnostics and crash reports — 30 days, deleted automatically.
• Study Lab execution reports and their diagnostics — 90 days, deleted automatically. Your study plan and coverage snapshot are a single current row that each new one replaces.
• Consent receipts — kept for as long as we need them to show the history of what you agreed to. They are append-only by design: never edited, never deleted. That is the point of a receipt, and it carries no name.
• Your ACGME import record, your attending feedback answers, your logging-time samples, your entitlements, your evidence suggestions, your invite links and redemptions, your ambassador record, and your class-group membership — for as long as the Service operates, unless you ask us to remove them. These have no automatic expiry and no delete button today; the email path under Deleting your data reaches all of them.
• A program-verification request — 90 days from the day you sent it, then deleted, or sooner if you take it back. Residents’ answers and evaluations to it go with it: they are stored only against the request and are deleted the moment it is, by either clock.
• Reliability events — kept with the other operational records; they carry no free text and are never joined to a case.
• Your program’s roster and the ACGME form structure — kept as long as they are current, because they describe your program and the ACGME form rather than you. Pairing credentials last until you or we revoke them.
• Push tokens — until you turn OR-board alerts off, or until Apple tells us the token is dead, whichever comes first.
• OR board snapshots — kept as a history of the department’s own board while the mirror runs. They are not keyed to you and there is no row in them that says which device you are.
• Beta, waitlist, and program signups — until we finish inviting for that specialty (or answering that program), or until you ask us to delete yours, whichever comes first.
• The updates list — until you unsubscribe (one click from any updates mail) or ask us. An unsubscribed address stays on the list marked do-not-mail, so it cannot be re-added by a later form submission; ask us and we delete the row outright.
• Feedback board email addresses — until you ask us to delete yours.
• Follow-up mail records — one row per mail we queue, holding the address only until the mail is sent or given up on, at which point the address is masked and only the masked form remains.
• Rate-limit counters — deleted after 24 hours. Each counter is a keyed one-way hash of the IP address, so there is no address to keep in the first place; a connection that keeps sending gets a fresh counter, and every counter is swept once it is 24 hours old.
• Account audit records — what changed on your account and when. These are retained when the account is deleted: the deletion cascade removes the account record, the device links, the observer credentials and the verification evidence, and it deliberately leaves the audit trail, which is also the ledger that lets an interrupted deletion finish. It carries no name.
• Pairing credentials (the browser extension’s) — until you or we revoke them, or until they expire. A revoked or expired credential is rejected on the very next request it is used for; there is no window where it still works.
• Ordinary server logs — the request records any web service writes. Kept for a short rolling period and then overwritten. We are not giving you a number here because the exact window is set by our hosting provider rather than by our code, and a number we cannot verify is worse than this sentence.
• Support and privacy email — kept while your question is open, and afterwards as a record of what was asked and answered. Ask us to delete a thread and we will.
• Resend’s delivery logs — held by Resend under its own policy, for every mail it delivered: the verification codes, the signup follow-up, the tips series, the receipts and the renewal notices. For a code we hold none of the address ourselves; for the rest, the rows above govern what we keep.
• Routine database backups — a deleted row can survive in a backup for a limited period after deletion, until that backup rotates out and the row goes with it. Backups exist so an outage is not a data loss; they are never used to restore something you asked us to delete.
• Anonymized statistics — permanent. Once an average is published it cannot be unpublished, which is why nothing identifying goes into one.

How deletion propagates. A switch purge is sent the moment you flip it, and is held and retried if your phone is offline. An email request runs on the timeline under Deleting your data. Backups fall out on the provider’s own rotation, which is the one part of this we do not control.

You can export your full case log to a file you control (the export excludes the private note and contains no patient identifiers by construction), delete any single case, or erase all data at once. Erasing wipes the local encrypted database and your keys, and also deletes your iCloud backup — across your devices. Deleting your Capnolog account is a separate switch and leaves the cases on your phone alone; uninstalling removes the local encrypted database.

Turning off case sync deletes your de-identified case data from our servers immediately — that request is not a soft delete or a pause, it’s a purge. Turning sync back on starts fresh from what’s currently on your device. The control is the case-sync switch in Settings → Data, backup & export (the one-time notice offers the same button); the email path below reaches the same purge if you would rather write.

Research sharing has its own switch and its own purge, on the same terms: turning it off deletes every case fact that install ever published, rather than merely stopping new ones.

One honest detail about the word immediately. Both purges are sent the moment you flip the switch, and publishing stops on the spot either way. If your phone happens to be offline at that moment, the purge is held and goes out as soon as it can reach us — on the next connection or the next launch. Off becomes gone; on a plane it takes until you land.

For everything a button does not reach, see Deleting your data below.

Deleting your account does not delete your cases, and deleting your cases does not delete your account. They are separate on purpose: your case log lives on your phone, and the account is a small record on our side that links your devices. What exists is a handful of separate stores, and here is how to empty each of them.

First, what “Erase all data” actually covers. It is the button in Settings, and it reaches two things: everything on this device, and your iCloud backup. It does not reach our servers — the switches and the email path below are what do that. The iCloud half is reported as done only when iCloud confirms it: if the cloud step cannot complete, the app does not mark it finished, it tells you the erase is still pending, and it retries on later launches until iCloud acknowledges it. An erase that says it finished, finished.

These are seven different actions, not one. People conflate them, and the difference decides what actually gets deleted: erasing local data; deleting the iCloud backup; purging our copy of your case log; purging the case facts behind research sharing; deleting your Capnolog account; revoking the browser extension’s pairing; and taking back a program-verification request. Doing one does not do the others. The list below is one row per action.

• Everything on your device, and your iCloud Backup — Settings → erase all data. It drops the encrypted database, deletes every per-note, per-plan and per-preference key, destroys the key that unlocks the database file so the file on disk becomes unreadable even before the phone reclaims it, clears your settings, and deletes the iCloud backup. Because the backup key is shared across your own devices, that erase removes the backup from your other devices too. It asks for Face ID first, it cannot be undone, and the iCloud half is reported done only when iCloud confirms it — otherwise it stays pending and retries.
• Our copy of your case log — turn case sync off in Settings → Data, backup & export (or the one-time notice’s button). That purges it, as described just above; the email path below is there if you’d rather write.
• Our copy of your case facts — turn research sharing off in Settings. Same purge, same terms.
• Pairing credentials — revoke them in Settings, which cuts the browser extension’s access to your cases. A revoked credential is rejected on the very next request the extension makes with it; it does not linger until it expires.
• Your Capnolog account — Settings → Account → Delete account. It removes the account record, the ids of the devices linked to it, your training program, and any program-verification evidence we hold. Deleting is idempotent: asking twice is not an error, and an account that is already gone reports success. It leaves the cases on your phone alone — those are yours, and they are not stored in the account. Unlinking a single device instead (Settings → Account → Devices) removes only that device’s link and leaves the account and every other device intact.
• A program-verification request — Settings → Program verification → Take it back. That deletes the request from our server along with every resident’s answer and evaluation attached to it; a request you leave alone deletes itself after 90 days. The copy of an evaluation the app kept in your own records is yours, and goes when you erase your data.
• Delete the app — that removes the local encrypted database. It does not reach the server-side stores; use the switches above first if you want those gone too.
• Everything else — email privacy@capnolog.com and we will delete it. Some server-side stores have no button today, and we would rather name them than let you assume a switch covers them: your ACGME import record, your attending feedback answers, your logging-time samples, your push token, your Study Lab relay data, your beta, program, or updates-list signup, including the email address you gave us, your feedback board email address, your evidence suggestions and corrections, your invite links and redemptions, your ambassador record, your class-group membership, any evaluation you left as a resident (which otherwise goes when the student deletes the request), and any other feedback text you sent. Diagnostics and crash reports expire on their own in 30 days; tell us and we will remove them sooner.

Everything else — how the email request actually works

What to send. Act from the device where a switch exists — that is faster than we are and it reaches exactly the data that install produced. Where no switch exists, email privacy@capnolog.com and tell us what you want removed and the email address your account signs in with, which is the one handle that can be matched to server-side rows. The app does not show you a device or account id to quote, so please do not go looking for one.

How we verify it is you. We may ask you to confirm the request from inside the app, or to write from the address your account signs in with. That is the whole check — we are not going to ask you for identity documents to delete data we hold under an opaque id.

How long we take. We acknowledge a request within 10 days and complete a verified one within 45 days. Where the law allows it and a request genuinely needs longer, we may take one further 45 days, and we will tell you before the first period runs out rather than after.

What deletion does not reach, and why. Five things, named so you are not left assuming otherwise. Anonymized statistics that have already been published — averages across many residents, with the safeguards described under Anonymized statistics applied; there is no row of yours left inside one to pull out, and a published average cannot be unpublished. Consent receipts — a receipt is the record that you agreed, or declined, and deleting it on request would defeat the one job it has, for both of us; it is a version label, a decision, a timestamp, and a device id, with no name, no email, and nothing about a patient. Routine database backups — a deleted row can persist in a backup for a limited period, until that backup rotates out and the row goes with it; backups are never used to bring back something you asked us to delete. Server logs — ordinary request records, kept for a short rolling period and then overwritten. And anything the law requires us to keep, for as long as it requires it.

One honest limit on all of this. Because we hold no name — the account carries an opaque id, not you — a request by email sometimes cannot be matched to server-side rows on its own, and we are not going to start collecting identifying information in order to be able to look people up. Where that happens we will say so plainly rather than leave you waiting, and we will tell you which route does reach the data.

Capnolog is built for medical students, residents, and fellows training in the United States and for the programs that train them. Outside the US it is not directed at you and we do not support it — we do not tailor it to another country’s training requirements and we cannot tell you whether it fits the rules that govern your training. Using it anyway is not forbidden, and this section is what we owe you if you do.

We will still answer you. Email privacy@capnolog.com to ask for access to what we hold, correction of what is wrong, deletion, or to object to processing, and we will handle it on the same terms and the same timeline as any other request — see Deleting your data. You can withdraw consent to the optional switches at any time in the app, and withdrawing it does not undo processing that already happened lawfully.

Why we process it, in one sentence. Running the app for you is performance of the agreement you accepted; the optional switches — case sync beyond that, research sharing, usage analytics, crash reporting — rest on your consent; and keeping the Service working and secure rests on our legitimate interest in a product that functions without collecting more than it needs.

Two things we will not imply. Our servers and our processors are in the United States, so anything that reaches us is processed there. And we have not appointed an EU or UK representative — saying so plainly is more use to you than leaving it to be inferred from a section that never mentions it.

The awkward part, said plainly: usually we cannot tell it is you. Because your account holds an opaque id rather than your name, most of what we hold is keyed to that id or to a device identity, neither of which we can connect to a person. If you email us asking what we hold about you, we generally cannot answer from the email alone — not because we are stalling, but because the link genuinely does not exist, and we are not going to start collecting identifying information in order to be able to look you up. The practical route is to act from the device itself: the switches in Settings reach exactly the data that install produced. If you can give us something we can match — the address your account signs in with, or the email you used for the beta — we will use it.

No automated decisions about you. Nothing in Capnolog makes a decision about you that produces a legal or similarly significant effect. Progress forecasts and study suggestions are exactly that — suggestions on a screen you are free to ignore.

California, and the other states with comprehensive privacy laws, give residents a set of rights. Three statements first, because they are the ones people most want:

• We do not sell personal information. Not for money, not for anything else of value.
• We do not share it for cross-context behavioral advertising.
• We do not use it for targeted advertising — there is no advertising in Capnolog at all.

Your rights, wherever your state grants them: to know what we collect and why (the What we collect, in one place section is written to answer that without you having to ask), to get a copy, to correct what is wrong, to delete, to limit how sensitive information is used, and to appeal if we turn a request down. We will not discriminate or retaliate against you for exercising any of them — there is no worse tier, no degraded app, and no different price.

How to exercise them

• Submitting. Email privacy@capnolog.com and say what you want. There is no form to fill in, and you do not have to sign in to ask.
• Verifying. We may ask you to confirm the request from inside the app, or to write from the address your account signs in with. An authorized agent may act for you with your signed permission, and we may still confirm the request with you directly before acting on it.
• Deadlines. We respond within 45 days, with one further 45-day extension where the law allows it and the request needs it — and we will tell you before the first period runs out, not after.
• Appealing. If we turn a request down, reply to us with “appeal” in the subject line. We answer appeals within 45 days and will tell you why, and where your state provides one, how to reach its attorney general.

Four things worth stating flatly. We do not sell personal information and we do not share it for cross-context behavioral advertising. We do not collect the categories a state law calls sensitive personal information — and to head off the confusion that is easiest to fall into, your case log is about the cases you cared for, not about your health; your training year and program are professional facts, not medical ones. PostHog, Clerk, and Resend act as service providers and processors under contract, not as recipients free to use what they handle. And program-level anonymized statistics are not personal information about you.

One practical limit. Much of what we hold is keyed to a device rather than to a person, so some requests can only be carried out from the device that produced the data — the switches in Settings reach exactly that. Where that applies we will tell you which route works instead of leaving you guessing.

On health-privacy laws. Capnolog is not intended to receive patient identifiers: the case log is de-identified by design and records the kind of case, never whose, and patient context belongs only in the private note and plan fields that stay encrypted on your device. Your institution’s own policies may impose stricter obligations than anything here, and where they do, they govern what you may put in the app. We do not currently provide a business associate agreement, and we do not represent that using Capnolog satisfies any institution’s compliance requirements — that is your institution’s determination to make. Our operating model may change, and we will update this policy and the Terms of Use if it does.

Capnolog is a professional tool for adults. You must be 18 or older to use it — it is built for medical students, residents, fellows, and physicians, and there is nothing in it for a child.

We do not knowingly collect personal data from anyone under 18. If we learn that we have, we delete it. If you believe a minor has given us something, email privacy@capnolog.com and we will remove it.

We will update this page as Capnolog changes, and the date and version at the top always reflect the version you are reading. That line is the answer to “is this current?” — if it has moved since you last looked, something below it has too.

For a material change — a new category of data, a new purpose, a new recipient — we will tell you in the app and ask you to agree to the updated Terms of Use before you continue, and this policy travels with them. Declining puts you in limited mode rather than locking you out; see If you decline updated terms above. For a minor change — clearer wording, a corrected detail — the new date at the top is the notice.

We do not apply a new material change retroactively to data already collected under the old policy without asking you first.

Questions about privacy? Email privacy@capnolog.com. For everything else, see Support. The agreement that governs your use of Capnolog is the Terms of Use.

By mail: Chockstone Labs LLC, 46 Shopping Plaza, PMB 5052, Chagrin Falls, OH 44022, USA.