SoloPractice (“SoloPractice,” “we,” “us”) is an electronic health record and practice-management system operated by Agyeman Enterprises for licensed medical practices and the staff and patients they serve. This policy explains what information we collect, why we collect it, who can see it, and the rights you have over it. It applies to the staff-facing clinical application and to the separate patient portal.
SoloPractice is healthcare software. Most of the information it holds is Protected Health Information (PHI) under the Health Insurance Portability and Accountability Act (HIPAA). We built this policy around what the application actually does today, not generic boilerplate — see docs/launch/LEGAL_COMPLIANCE.md in the SoloPractice repository for a note on what was verified directly against the codebase versus stated generically.
1. Who this policy covers
Two distinct populations use SoloPractice, with different data, different access, and different accounts:
- Practice staff— physicians, nurse practitioners, physician assistants, nurses, medical assistants, front-office and billing staff, and practice administrators. Staff authenticate with Supabase Auth (email + password, with multi-factor authentication required for clinical roles) and are assigned a role (e.g.
MD,MD_OWNER,NURSE,MA,ADMIN,FO) that determines what they can see and do. - Patients— who may be given portal access by their practice. Patients authenticate separately through a one-time-passcode (OTP)-verified portal session (a signed
portal_sessiontoken), not the staff login, and can only see their own records.
2. Information we collect
2.1 Patient demographic and contact information
Collected by practice staff at registration and check-in, or supplied directly by the patient through the portal: legal name, preferred name, date of birth, sex/gender identity, pronouns, medical record number, last 4 digits of Social Security Number, email, mobile/home/work phone, mailing address, preferred contact method, emergency contact, and photo (where used for chart identification).
2.2 Clinical and visit information
Chart data created and maintained by the practice: appointment and visit history, SOAP notes and other clinical documentation, vitals, diagnoses and problem lists, medications and e-prescriptions, lab and imaging orders and results, procedure and immunization records, consent forms, and AI-assisted visit summaries (drafted by an AI scribe and always reviewed and approved by a licensed clinician before becoming part of the permanent record — AI drafts are never auto-signed).
2.3 Insurance and billing information
Insurance carrier, member and group numbers, eligibility and prior-authorization results, claims and remittance data, invoices, and payment records. Card payment details themselves are collected and stored by our payment processor, Stripe — SoloPractice does not store full card numbers; it stores a Stripe-issued customer/payment reference.
2.4 Audio and telehealth data
Where a practice uses the ambient AI scribe, visit audio is sent to our transcription provider for speech-to-text conversion and then discarded from that provider once the transcript is returned; the resulting transcript and generated note remain in SoloPractice, scoped to the practice. Where a practice conducts video telehealth visits, audio/video is relayed through one of several supported third-party or AE-operated video providers (selected per practice) and is not recorded by default.
2.5 Account and technical information
Login timestamps, IP address, user agent, session identifiers, and system audit trail entries (see Section 6). We do not use third-party advertising trackers.
3. Who can access your information
Access is role-based and scoped to a single practice. SoloPractice is multi-tenant: every clinical and billing table is scoped by a practice_id, and database Row-Level Security (RLS) policies enforce that a user can only read or write rows belonging to the practice they belong to (verified directly in this codebase — see Section 6 below and LEGAL_COMPLIANCE.mdfor the specific migrations reviewed). Within a practice, what a staff member can see is further limited by their assigned role — for example, front-office staff can see scheduling and demographics but not full clinical notes; only clinicians and administrators can access diagnosis and treatment detail.
Patients can access only their own records through the patient portal: their notes, labs, imaging results, vitals, and billing — never another patient’s data, and never another practice’s data.
We do not sell patient or staff data. We do not share PHI with third parties except as described in Section 4 (service providers who process data on our behalf) or as required by law (e.g. a valid subpoena, public health reporting obligation, or insurance claims submission you or your practice has authorized).
4. Service providers we use
SoloPractice is built on a small number of infrastructure and service providers that process data strictly to deliver the features below. This list reflects what is actually wired into the application, not a generic vendor list:
- Supabase— our database, authentication, and file storage provider. All clinical, billing, and account data lives in a Postgres database with Row-Level Security enabled; uploaded documents (consent forms, lab PDFs, clinical photos) live in private, access-controlled storage buckets.
- Stripe— processes patient and practice payments. Card details are handled by Stripe directly; SoloPractice never receives or stores raw card numbers.
- AssemblyAI— converts visit audio to text for the AI scribe feature, when a practice uses it.
- Twilio— sends appointment-reminder SMS/voice messages and supports one telehealth video option, when a practice enables it.
- Video/telehealth providers— a practice’s telehealth visits are relayed through one of several supported video engines (which may include Twilio, LiveKit, or AE’s own Ghexit platform), selected in that practice’s settings.
- Resend— sends transactional email (appointment reminders, statements, portal invitations, one-time login codes).
- Amazon Web Services (S3)— used for bulk data export packages an administrator explicitly generates (e.g. a full practice or patient record export); export files are access-controlled and time-limited.
- Sentry— application error monitoring. Sentry is configured to strip request bodies, cookies, and authorization headers before any event is sent, specifically so clinical note content, session tokens, and PHI are not transmitted to this third party.
- Anthropic (Claude)— powers AI-assisted note drafting and clinical-decision support. AI output is always a draft; a licensed clinician reviews and signs before it becomes part of the medical record.
Where PHI is disclosed to a service provider above in the course of providing services to a covered healthcare practice, that arrangement is intended to operate under HIPAA’s business-associate framework. See Terms of Service § 8 and LEGAL_COMPLIANCE.md for the current status of underlying Business Associate Agreements (BAAs) with these providers.
5. How your information is stored and protected
- All traffic to SoloPractice is encrypted in transit (HTTPS enforced via HTTP Strict Transport Security).
- Data is stored in a Postgres database with Row-Level Security enabled on patient-facing tables, scoped by practice.
- The most sensitive identifiers — Social Security Number and date of birth — are additionally protected with column-level encryption at rest.
- Document storage buckets (consent forms, lab documents, clinical photos, scribe recordings) are private by default; files are served only via short-lived signed URLs, never public links.
- Every privileged clinical action — note approval, visit signing, consent signing, bulk export, staff account creation, right-to-erasure requests — is written to an append-only audit log capturing who did what, when, and from which IP address.
- Multi-factor authentication is required for clinical staff roles.
6. Data retention
We retain clinical, billing, and audit records for at least six years, consistent with HIPAA’s documentation-retention requirement (45 CFR § 164.316(b)(1)) and applicable state medical-records retention law, whichever is longer. Audit log entries are never deleted by the application and are additionally archived annually to secondary storage as a compliance backstop. A practice may have additional retention obligations under its state’s medical board rules; those obligations are the practice’s responsibility as the HIPAA covered entity.
7. Your rights
7.1 Access and correction
Patients can view their own visit notes, labs, imaging results, vitals, and billing history at any time through the patient portal. To request a correction to your record, contact your practice directly — the medical record is legally the practice’s responsibility, and corrections to clinical documentation follow HIPAA’s amendment process (45 CFR § 164.526).
7.2 Right to erasure
Where applicable law grants a right to erasure (for example, GDPR Article 17 for patients within scope of EU/UK data protection law), a practice administrator or owning physician can invoke an erasure request for a patient record. This irreversibly anonymizes the patient’s identifying fields (name, date of birth, contact details, SSN, insurance identifiers, address, emergency contact, clinical note text) while preserving the underlying clinical/billing record structure and diagnosis coding required for regulatory and financial recordkeeping, and purges the patient’s uploaded documents from storage. The request itself is recorded in the audit log. Note that HIPAA’s six-year retention requirement and a practice’s medical-records law obligations can limit or delay full erasure of clinical records even where a general privacy-law erasure right applies — your practice can explain what applies to your record.
7.3 Portability
Patients can request a copy of their record from their practice. Practice administrators can generate a structured export of a patient’s or the full practice’s data through the application’s export feature.
8. Breach notification
In the event of a breach of unsecured PHI, we will notify affected practices without unreasonable delay and in accordance with the HIPAA Breach Notification Rule (45 CFR §§ 164.400–414), so that practices can meet their own notification obligations to affected patients and, where required, regulators.
9. Children’s information
SoloPractice is used by medical practices to hold records for patients of any age, including minors, as part of normal pediatric and family-practice care. This is clinical recordkeeping performed by a healthcare provider, not a consumer service directed at children, and is not subject to COPPA’s consumer-app requirements. Access to a minor patient’s portal account is controlled by the practice in accordance with applicable minor-consent and parental-access law.
10. Changes to this policy
We may update this policy as the product changes. Material changes affecting how PHI is handled will be communicated to practice administrators. The “Last updated” date at the top of this page reflects the most recent revision.
11. Contact
Questions about this policy, or to exercise a privacy right described above, contact: [email protected]. For a specific patient record, please also contact your practice directly, since the practice — not SoloPractice — is the HIPAA covered entity responsible for that record.
This policy is a good-faith, product-grounded description of current data practices and does not by itself constitute a Business Associate Agreement. See docs/launch/LEGAL_COMPLIANCE.md for review status.