Security & data
Local records.
Clear boundaries.
Core records and imaging run on practice-controlled Windows hardware. Security also depends on the device, the practice’s procedures, and any connected services it chooses to configure.
On your hardware
Local storage
Patient records and source imaging files are stored locally. A local-first design does not mean every optional feature works without the internet.
Storage protection
Different files, different safeguards
Structured patient records and clinical notes use application encryption. Imported DICOM, STL, and x-ray source files rely on device-level storage protection. Whole-device encryption such as BitLocker is recommended.
When connected
Know what leaves the device
License and update requests use the internet without clinical content. Optional cloud note drafting, messaging, payments, and explicit case sharing can transmit data when configured or initiated.
Licensing has its own data
The paid location-license design uses billing and subscription identifiers, treatment-address information, installation and database identifiers, and device fingerprints. Licensing requests do not include patient records. The licensing service and Keygen have defined roles in this process.
Safeguards are not a compliance certificate
Access controls, audit logging, backups, device protection, and appropriate provider agreements are parts of a practice’s security program. Connected-service and release validation remain in progress. The Practice Assistant and live insurance eligibility connection are not currently available.
What can leave the device?
Optional vendor integrations require practice configuration and the applicable provider agreements. Capabilities marked future are not available today.
| What | Sent where | When |
|---|---|---|
| Licence validation | The licensing service | For paid features. Carries no patient information. |
| Update check | The update feed | On launch. Carries no patient information. |
| AI note drafting | Nowhere by default: it runs on your own computer. Optionally Google Gemini, under your own API key. | Only if you switch away from the on-device default; requires a paid licence and an explicit BAA acknowledgment. Google's consumer AI API offers no BAA. |
| Practice assistant (chat) | Future Conductor capability; not currently available. | If released, its cloud-only provider, BAA/configuration, consent, and outage gates must pass before use. |
| Text messages | An SMS provider, under your own account | Opt-in, behind an SMS BAA acknowledgment. |
| Your own mail server | Opt-in, behind an email BAA acknowledgment. | |
| Card payments | Stripe, under your own key; charges carry a patient or contract reference | Opt-in, behind a Stripe BAA acknowledgment. |
| Insurance eligibility | Future clearinghouse connection; currently dormant. | A later release must bind the exact provider account, endpoint, credentials, BAA evidence, and successful synthetic payer test before any live request is enabled. |
| Referral case sharing | An OrthoTruss-run relay | Only when you share a case. The case package is sealed on your computer and the key travels only in the link, so the relay cannot read it. The relay holds the sealed package, the recipient's email, and a case reference for up to 90 days, then purges them. |
| Multi-workstation sync | Other workstations on your own network | Opt-in. Encrypted in transit, between the workstations the practice pairs. |
| Patient portal & booking | Your own machine | Off by default; reachable only if you enable it. |