Legal
Privacy Policy
About This Policy
Who this policy is for. This policy is for healthcare practices that use Sefton ("Customers"), the people who work in them, and visitors to our websites. If you are a patient using the patient portal or a telehealth visit, your policy is the Client-Portal Privacy Policy, and your provider's Notice of Privacy Practices describes your rights. This policy is not a Notice of Privacy Practices: under 45 CFR 164.520 that notice is issued by your healthcare provider, not by Sefton.
The policy has three parts. Part A covers information Sefton collects for its own business: accounts, billing, our websites. Part B describes what Sefton does with patient information it processes for Customers as their business associate. For patient information, the Business Associate Agreement ("BAA") between Sefton and each Customer controls, and Part B summarizes it. Part C describes how we measure use of the Service and our websites.
A1. What we collect
- Account and profile data: names, work email, phone, role, practice, professional credentials (such as NPI and license details), and sign-in data, including passkeys/WebAuthn and identity-provider metadata.
- Billing and subscription data: plan, seats, invoices and payment-processor tokens. Card data is handled by our payment processor (Stripe) and is not stored by us. These records contain no patient information.
- Website and app technical data: logs, device and browser data, IP address, and diagnostics. See the Cookie Policy for website cookies.
- Communications: support requests, sales inquiries and feedback you send us.
A2. How we use it
To create and secure accounts; to provide, support and bill for the Service; to send service, security and billing notices; to respond to inquiries; to improve our websites and the Service; and to comply with law. We may send product updates by email, and every such email has an unsubscribe link.
A3. Sharing
We share Part A information only with service providers that help us run the business (hosting, payments, email delivery, customer support), under contracts that limit their use to our instructions; when the law requires it; or in a merger, acquisition or sale of assets, subject to this policy. We do not sell personal information and we do not share it for cross-context behavioral advertising.
A4. Retention
We keep account and billing records for the life of the account and then as long as tax, accounting and legal-hold obligations require. Website logs age out on a fixed cycle.
A5. Your choices
You can update account details in Settings, unsubscribe from product email, and ask us at privacy@sefton.health to access, correct or delete Part A information about you. We answer within 45 days. Deleting a user account does not delete patient records the practice keeps, which Part B governs.
B1. Roles
Each Customer is a covered entity under HIPAA (or a business associate of one) and controls the patient information in its account. Sefton is the Customer's business associate. We create, receive, keep and send protected health information ("PHI") only to provide the Service to that Customer and only as the BAA and 45 CFR 164.504(e) permit.
B2. Categories of PHI the Service holds
Patient demographics and contact details; appointments; clinical notes and documents; intake and assessment responses; messages between the practice and its patients; telehealth recordings and transcripts where the patient consented; claims, eligibility, remittance and billing records; and portal-use records described in the Client-Portal Privacy Policy.
B3. What we do with PHI
As the BAA permits, Sefton uses and discloses PHI to:
- run the Service for the Customer, including the treatment, payment and healthcare-operations functions the Customer directs (scheduling, documentation, claims, messaging, telehealth);
- support automated documentation, transcription and translation features the Customer turns on, under the Telehealth Recording, Transcription and Automated Documentation Consent the patient signs;
- secure the Service, investigate incidents and give breach notice as 45 CFR 164.410 requires;
- use subcontractors bound by business associate agreements (B5); and
- comply with law. If we receive a subpoena or other legal demand for a Customer's PHI, we will notify the Customer before disclosing, unless the law forbids it, and disclose only the minimum necessary.
B4. Limits we hold ourselves to
- We do not sell PHI or personal information.
- We do not use PHI to train, fine-tune or improve any AI or machine-learning model, first-party or third-party, other than solely to deliver the contracted feature to the Customer whose patient supplied it. We do not use de-identified data derived from PHI to train models offered to other customers.
- We do not use PHI for advertising.
B5. Subprocessors
PHI-bearing subprocessors operate under signed business associate agreements. Today they are AWS and Claim.MD: Amazon Web Services for hosting and HIPAA-eligible processing, and Claim.MD for clearinghouse and ERA. Within AWS, PHI is processed by Amazon Bedrock, Amazon Transcribe, Amazon Translate and Amazon Polly when a feature that uses them is in use; B10 describes what each receives. Payment, push-notification, identity and source-control vendors are kept out of PHI scope. The current list is published at sefton.health/trust, and we give notice there and by email before adding a PHI-bearing subprocessor.
B6. De-identified data: benchmarks and research
Unless a Customer turns it off, we use data de-identified under 45 CFR 164.514 to produce combined benchmarks (for example coding mix, denial rates and payer performance), shown only to practices that contribute and only when enough practices contribute that no one practice's figures can be worked out. Separately, unless a Customer turns it off, we use de-identified, combined data for research and may publish findings that never identify a patient, clinician or practice. Customers control the two uses with separate settings under Settings > Data sharing; turning one off does not affect the other. Neither use involves selling data, attempting re-identification, or training AI models. A patient who asks their provider to be excluded from research will be excluded.
B7. Security
Encryption in transit and at rest; access controls and least privilege; multi-factor and passkey sign-in; tenant isolation; PHI-aware audit logging; secrets management; and security headers and origin controls. No system is perfectly secure, and we maintain an incident-response and breach-notification process.
B8. Retention, return and deletion
We keep PHI as long as the Customer's account needs it and as the Customer instructs. On termination we provide an export of Customer data in a structured format within 30 days of the Customer's request, then return or destroy PHI as the BAA requires. A telehealth recording is a working file by default and is deleted 30 days after the visit note is signed, or 30 days after capture if no note is signed. A recording the clinician marks as part of the record before signing is kept at least 10 years after the patient's last entry or discharge and, for a minor, at least until age 28; a practice may lengthen these periods but not shorten them. Audit records of access to PHI are kept for 7 years. Records under a legal hold are kept until the hold is released.
B9. Patient requests
Patients exercise their HIPAA rights (access, amendment, restriction, accounting of disclosures, confidential communications) through their provider, the covered entity. If a patient contacts Sefton directly, we refer the request to the provider promptly and help the provider fulfil it.
B10. AI services and what they receive
Some features send PHI to AI services that run in Amazon Web Services under the AWS business associate agreement (B5). Sefton sends this data only to AWS.
- Amazon Bedrock: drafts visit notes from telehealth transcripts and dictation (the request includes the patient's name, the session title and date, and the transcript); suggests billing codes from note text and, where the clinician asks for suggestions in context, from the patient's diagnosis on file, treatment goals and codes billed before; drafts and improves appeal letters (patient name, date of birth, claim number, service date, amounts and codes, and the provider's NPI and contact details); organizes telehealth transcripts and summarizes meeting transcripts; interprets provider voice commands; answers questions that providers type into AI assistant features; answers the in-app help assistant, after identifiers it detects are removed; and checks the quality of machine translations of messages and interpreted conversations.
- Amazon Transcribe: telehealth, dictation and voice-command audio, to produce text.
- Amazon Translate: telehealth captions, messages between the practice and its patients, interpreted conversations, and portal content such as home programs, intake forms, goals, shared notes and notifications, when the reader's language differs from the writer's.
- Amazon Polly: text a provider asks to have read aloud, including the translated captions of what a patient says in a video visit when the provider turns on spoken translation.
Every AI output is a draft that the clinician reviews (AI-Features Addendum). The limits in B4 apply: PHI is not used to train any model.
C. Measurement and analytics
The Patient Portal Privacy Policy describes how we measure use of the patient portal. This section describes the other ways we measure use of the Service. Every measurement below is recorded by our own servers into our own database, except Google Analytics on our public website, which is described in its own paragraph below. We do not load any third-party analytics or session-replay script in the Service: the provider app, the patient portal, and our iOS app.
First-use milestones and account setup (providers). When a provider account uses a feature for the first time — for example the first voice command, the first translated session, or the first transcript that completes — and as a provider reaches each step of account setup, we record that milestone once. Each record holds the milestone name; a keyed one-way hash of the account and practice identifiers rather than the identifiers themselves; the role, workflow, platform (web, iOS, or server) and outcome; and a short list of permitted descriptive values such as the language pair or the setup step number. There is no field for names, notes, messages, or other content. Setup steps are recorded by our server as you move through setup, not by a script in your browser. These records are read as counts per milestone, by Sefton administrators only, to see which features are adopted and where setup is abandoned.
Language and workflow timing. For interpreted or translated encounters we record the encounter type, the languages involved, the number of utterances, the duration, and the outcome, together with hashed practice, clinician, and patient identifiers. For the time it takes to move from a visit to a signed note and a submitted claim we record timestamps and durations for each stage; that record keeps the internal visit, patient, and clinician record identifiers so the stages can be tied together. Neither record holds transcript, note, or message text. Timing is shown to a provider for that provider's own visits, and to anyone else only as totals and averages.
Weekly rollups and the research page. Once a week we compute, for each practice, totals such as claims filed, notes signed, active clinicians, multilingual sessions, and languages used, and per-language totals in which patients appear only as a count of distinct hashed identifiers. Figures on our public research page come either from snapshots we publish deliberately, each with a sample size of at least five, or from live totals that are withheld until at least five records exist.
Network benchmarks (providers). A practice's adjudicated claims can contribute to cross-practice benchmarks. The automatic contribution computes three rates — denial rate, clean-claim rate, and average days to payment — and the pool accepts at most six named rates in total and nothing else. Each contributed rate is stored with keyed one-way hashes of the provider identifier and of the practice identifier, the specialty and provider type, and the month (never the day) it relates to. Contribution runs automatically, at most once per month per provider, for providers who have not turned it off, and does not run at all if the hashing key is not configured. Each benchmark figure is shown only when at least five distinct practices contributed to it and no single practice contributed more than a quarter of the data behind it, and peer patterns only when they are drawn from at least ten practices. Contribution is on by default; the Service keeps a per-provider preference that turns it off.
Website attribution. When you first arrive at our website or the Service, a first-party cookie named sef_ft stores, for 90 days, the referring site, the first page you landed on, and any campaign tags in the address (utm_source, utm_medium, utm_campaign, utm_term, utm_content). If you then register a provider account, those values are saved with the new account together with the registration request's referer, IP address, and browser user agent, so we can see how practices find us. The cookie is set for the sefton.health domain only.
Google Analytics on our public website. On our public marketing website only, we use Google Analytics, a service provided by Google LLC, to count visits and to learn which pages and sign-up buttons are used. Pages inside the Service, pages for patients, and website pages that signed-in users or patients reach from the Service (payment confirmations, the referral page, and our legal documents) never load Google Analytics. On the pages that do, Google receives the address of the page, the site that referred you, device and browser details, and an approximate location derived from your IP address, and sets the cookies described in our Cookie Policy. When you select a button that leads to sign-up, we record which button it was. When a provider registers an account, our server sends Google Analytics a single "sign_up" event tied only to the random identifiers in that browser's Google Analytics cookies. The event contains no name, email address, practice, or account information, and it is sent only if the browser has a Google Analytics cookie and the browser did not send a Global Privacy Control signal. We never send health information to Google. Google signals and ad personalization are turned off. Google has not signed a Business Associate Agreement with us, which is why Google Analytics is limited to the public website. If your browser sends a Global Privacy Control or Do Not Track signal, our website does not load Google Analytics, and you can block or delete its cookies in your browser settings at any time.
Who sees what, and for how long. Milestone counts, rollups, and benchmark inputs are read by Sefton administrators in the administration console. Practices see benchmarks only as pooled figures, and workflow timing only for their own visits. The public research page shows only the published and threshold-protected figures described above. We keep these measurement records under A4 and B8; no separate, shorter retention period is currently applied to them.
General
United States only. The Service is operated in the United States for U.S. healthcare use.
Children. Sefton's websites and provider accounts are not directed to children. Information about pediatric patients is PHI handled under Part B at the provider's direction.
Changes. We will notify Customers by email or in the product at least 30 days before a material change takes effect. The effective date above shows the current version.
Contact. privacy@sefton.health · Sefton Health, Inc., 31 E Newell Avenue, Rutherford, NJ 07070. Anyone who believes their health-privacy rights were violated may complain to the U.S. Department of Health and Human Services, Office for Civil Rights (www.hhs.gov/ocr/privacy/). We will not retaliate against anyone for filing a complaint.