Encryption
TLS protects data in transit, including the connection to the database, whose certificate is verified. Data is encrypted at rest by our database host. Credentials never live in the application bundle.
Role-based access and tenant isolation
Four roles: administrator, biller, front desk and read-only. Posting, adjustments, voids and write-offs are limited to billers and administrators, and practice analytics to administrators. Every request is checked against the practice it belongs to.
Amounts are never edited
A financial correction posts as a reversal rather than an edit to a posted amount, so the money trail reads forward and reconciles to the cent.
Audit log
Key actions are recorded with the user, the action and the time: sign-in, claim submission, corrections and voids, discounts, payment plans, imports, lab orders, check-ins and integration keys.
Sign-in and session security
Two-factor sign-in with any authenticator app, which an administrator can require for the whole practice, plus one-time recovery codes. Accounts lock for 15 minutes after five failed attempts. Sessions are signed, stored in an HTTP-only cookie and validated against the user record on each request, so a revoked account loses access immediately.
Secrets stored as hashes
Integration keys, patient check-in and portal links, and recovery codes are stored only as SHA-256 hashes, and authenticator secrets are encrypted, so a copy of the database does not yield working credentials. Patient links lock after repeated wrong dates of birth. Card numbers are entered on Stripe's hosted page and never reach our servers; only the card brand and last four digits are kept.
HIPAA alignment
A practice using the platform is the covered entity; we are its business associate. A business associate agreement is available on request and is signed before any protected health information is loaded. It sets out what we may do with protected health information, how long we keep it, and what happens to it when the relationship ends. The technical safeguards above map to the Security Rule: access control, audit controls, integrity and transmission security.
Standards we implement
Claims and remittances are generated and parsed as real ASC X12 transactions rather than passed through a conversion layer: 837P for professional claims, 835 for remittance advice, 270 and 271 for eligibility, and 999 and 277CA acknowledgments; EHR and lab traffic is HL7 v2. Each is covered by segment-level tests, so a change that would alter a segment fails before it ships.
Reporting a vulnerability
If you believe you have found a security issue, tell us through the contact page and select the security topic. Please include enough detail to reproduce it, and give us a reasonable period to investigate before publishing. We will confirm receipt within two business days.
Related reading
The Privacy Policy covers what we collect and why. The GDPR page covers lawful bases, transfers and data subject rights.