Dr. Notes keeps patient information on the clinician's device by default — no cloud account, no server-side PHI, no third-party transcription pipeline. This page explains what that means for HIPAA: why an offline app reduces the surface a clinician has to defend, the specific controls Dr. Notes ships, and how the model compares with a typical cloud EMR/EHR.
HIPAA's Security Rule (45 CFR § 164.302–318) doesn't require a particular architecture. It requires that a covered entity put administrative, physical, and technical safeguards in place to protect electronic protected health information (ePHI). An offline-first design clears several of those requirements by shrinking the attack surface rather than defending it.
Dr. Notes stores patient details, clinical notes, medications, allergies, vaccinations, documents, and voice recordings in the app's local Core Data store. There is no Dr. Notes server, no shared multi-tenant database, and no required online account. Network access is optional — used only for features the clinician explicitly opts into (such as iCloud backup or sharing an exported document). When the app is offline, no PHI is in transit, no PHI is on a vendor's server, and there is no Dr. Notes-side endpoint that could be breached on the clinician's behalf.
Voice notes are transcribed on the device using a local speech model bundled with the app. Audio is not uploaded to a transcription API. For HIPAA, this matters because no Business Associate Agreement (BAA) is needed with a third-party transcription vendor — the audio simply never reaches one.
Backups are produced as a single encrypted archive on the device. The clinician chooses a passphrase; Dr. Notes derives a key from it and seals the backup with AES-GCM authenticated encryption, plus a SHA-256 integrity checksum that fails the restore if the archive has been tampered with. If iCloud sync is turned on, the encrypted archive rides on Apple's iCloud infrastructure — which the clinician controls through their own Apple ID — rather than on a Dr. Notes-operated cloud.
The Security Rule defines a set of safeguards that any clinician handling ePHI is expected to put in place. Below are the technical controls Dr. Notes implements in the app today, mapped to the category each one addresses.
Every create, update, delete, view, export, and import of a patient, clinical note, appointment, invoice, medication, allergy, vaccination, or document is recorded in a local audit log. Settings → Audit Logs lets the clinician filter by Today, Last 7 days, Last 30 days, Last 12 months, a specific date, or a custom range.
Backups are sealed with AES-GCM (authenticated encryption) using a key derived from a user-chosen passphrase, and gated by a SHA-256 checksum. Tampering or partial corruption is detected at restore time — the archive will not import silently.
Dr. Notes works fully offline. Patient data does not traverse a network unless the clinician explicitly chooses to share or back up. There is no telemetry pipeline, no analytics SDK that collects PHI, and no third-party transcription upload.
Dr. Notes inherits iOS's device passcode, Face ID, Touch ID, and Data Protection — meaning the local store is encrypted at rest by the operating system whenever the device is locked. The clinician is responsible for keeping a passcode and biometric lock enabled on the device.
The clinician can export any patient's record or delete it from within the app. Deletions cascade through related entities (notes, medications, documents, audit references) and are themselves recorded in the audit log.
An auto-backup scheduler can produce regular encrypted backups so a hardware failure doesn't lose months of patient history. Backups are portable: an archive made on one iPhone or iPad can be restored on another after re-installing the app.
Because there is no Dr. Notes server, no employee can ever see a patient record. The principle of minimum necessary disclosure is enforced by the architecture itself — there is no human inside the vendor with access to disclose.
All privacy-relevant settings — backup passphrase, audit log, export, delete, transcription engine — are in plain language in Settings. The smaller the gap between policy and what staff see on screen, the easier HIPAA training is to enforce.
Cloud EMR/EHR products are the right answer when a practice needs multi-user concurrent access, hospital integrations, claims clearinghouses, or a large team's revenue cycle. They are heavier when a single clinician or small clinic just needs reliable notes without an internet dependency, and they carry a larger HIPAA surface area in exchange.
| Concern | Dr. Notes (offline-first) | Typical cloud EMR/EHR |
|---|---|---|
| Where PHI lives | On the clinician's device, in the app's encrypted local store. | On the vendor's multi-tenant servers; you depend on their controls. |
| Need for a BAA with the app vendor | Not required — Dr. Notes does not receive PHI. | Required — the vendor is a Business Associate handling your PHI. |
| Internet dependency | None. Works fully offline; sync is opt-in. | Required. Outage = no patient notes. |
| Voice-note transcription | On-device. Audio never uploaded. | Usually a cloud API; PHI in transit and at the vendor. |
| Breach surface | One device per clinician. No vendor-side multi-tenant data. | Vendor-side breach can expose many practices at once. |
| Audit log of who-saw-what | Local audit log of create / update / delete / view / export / import per entity. | Server-side audit log; access is sometimes hard to inspect for a small practice. |
| Backups | Local, AES-GCM encrypted, integrity-checked, portable. | Vendor-managed; restore SLA and granularity vary by plan. |
| Subpoena / discovery surface | Records live with the clinician; no vendor-side custodian. | Vendor may be served independently of the practice. |
| Best fit | Solo clinicians, small clinics, field/home-visit workflows, low-bandwidth settings. | Multi-doctor practices needing concurrent access, scheduling, billing, hospital integrations. |
This page describes how Dr. Notes is designed to support HIPAA-aligned clinical workflows and is provided for informational purposes only. It is not legal advice. Practices remain responsible for their own HIPAA compliance program. For specific questions, consult your compliance counsel.