HIPAA Status

This page says what Elizabeth AI does today to protect patient information, what it does not yet do, and where your patients’ data goes. Where a control is missing, we say so rather than describe a plan as if it were in place. We are not lawyers, and nothing on this page is legal advice.

01Our role and the agreements

Under HIPAA your practice is the covered entity and Elizabeth AI Receptionist LLC is your business associate. We receive, store and transmit protected health information (PHI) only to perform the services you engage us for: answering and placing calls, booking and changing appointments, taking refill requests and messages, sending appointment texts, and reporting outcomes to your staff.

Practice BAA. We sign a Business Associate Agreement with every practice before any patient traffic reaches the system. It is executed directly between your practice and Elizabeth AI Receptionist LLC and is presented for electronic signature during onboarding; checkout cannot be completed until it is signed. Its current draft commits us to: use and disclose PHI only as the agreement or the law permits; the safeguards in force on its effective date, with a section that expressly lists the controls not yet implemented (no application-level encryption at rest, no required multi-factor authentication, subcontractor agreements not all executed); reporting of unauthorized uses, security incidents and breaches to your practice (section 06); written agreements with every subcontractor that touches PHI, with disclosure of which are not yet executed; making PHI available for patient access, amendment and accounting of disclosures; and return or destruction of PHI when the agreement ends (section 05).

Status. The BAA template is a draft that has not yet been reviewed by an attorney, and no practice has signed it. An earlier version of the agreement, generated in April 2026 and still stored in our system, describes safeguards that are not in place (encryption of PHI at rest, required multi-factor authentication, regular security assessments) and a 24-hour breach-notice window; it will be replaced before any practice signs. New practice sign-ups are closed until the subprocessor agreements below are executed.

Subprocessor BAA status, as of 29 September 2026. We are candid about this because you should not have to take it on trust: our agreements with the vendors in our data chain are in progress, not yet executed. Until each is signed, that vendor is not cleared to process PHI, and no practice is onboarded to live patient traffic against an unsigned chain.

Two earlier vendors, Amazon Web Services (call analytics until April 2026) and Telnyx (our former carrier), carry no current traffic. Records that reference them remain in our database, and recordings they made may still exist on their systems; we have not confirmed deletion. They handled only our own test and staff calls and the few stray calls described in section 04; the system has never held a real patient’s record.

Ask us for current status in writing before you sign anything. We will confirm exactly which agreements are executed on the date you ask.

02Where patient data goes

Each vendor below that can see PHI needs an agreement of its own (section 01). The application stores no patient information on practice workstations or on the kiosk tablet.

• Phone calls. A caller reaches your practice’s number at Twilio. Twilio connects the call to our voice vendor, xAI, which hears the audio, transcribes it, generates Elizabeth’s replies and speaks them. Call audio does not pass through our server. During the call the assistant sends requests to our server — to confirm identity, look up and book appointments, and record refill requests and messages — and our server stores each request with its arguments and result (the caller’s name, date of birth, appointment and medication details as the assistant relayed them), plus a summary of the call built from those requests. On the current voice path we do not receive or store a full transcript; xAI keeps its own turn-by-turn transcript, which we have observed in its console for about 30 days. Calls made before mid-August 2026 on our earlier voice stack do have stored transcripts.
• Outbound calls. Care-gap and follow-up calls run the same way in reverse: our server asks Twilio to dial the patient, xAI conducts the call, and the assistant reports the outcome and any reading the patient gave back to our server, where they are stored.
• Text messages. Appointment texts, refill updates and consent messages go through Twilio. Their bodies name the practice and carry the appointment date, time and provider, the medication name in refill updates, and the patient’s name in care-gap follow-up texts. Twilio keeps message content and delivery records.
• Staff notifications. Call-outcome cards and clinical-reading alerts are posted to Microsoft Teams; they carry the patient’s name and, for readings, the values the patient reported (blood pressure, blood sugar, A1c, oxygen saturation, cholesterol). Campaign digests and other staff email go through Microsoft Power Automate.
• Pharmacy look-ups. When a caller names a pharmacy, its name and area are sent to Google Maps to find the address; the caller’s name and number are not.
• Web, dashboard and kiosk. Every web request, including the staff dashboard, the check-in kiosk and our API, passes through Cloudflare, which terminates TLS at its edge and can therefore see that traffic in the clear before re-encrypting it to our server.
• EHR systems. Our Epic, athenahealth and Oracle Health integrations are registered against those vendors’ sandboxes only. No practice’s live EHR is connected today.
• Storage. Our database is one file on one Google Cloud virtual machine in the us-central1 region (Iowa, United States), alongside the server’s own logs and manual database backups. A development copy of the database from before the August 2026 move to Google Cloud remains on the company’s development computer (section 04).
• Billing. Stripe receives your practice’s billing contact and card details, never PHI.

03Technical safeguards

We are building toward full HIPAA Security Rule alignment. The current status of each control is stated below, including the gaps.

04What we store, and for how long

What we store. For each call: the caller’s number, timing and outcome; the requests the assistant made to our server with their arguments and results; and a summary. For calls before mid-August 2026 on our earlier voice stack, a full transcript. For each text message: the message body, the patient’s name and the delivery status. Patient records your practice loads or the assistant creates: name, date of birth, phone number, appointment details, refill requests with pharmacy details, messages for staff, readings the patient reports, insurance details entered at the kiosk (carrier, member ID and group number), and consent records. Application logs on the server also contain call and request details; phone numbers, email addresses and dates of birth are masked by pattern before they are written, names are not.

What we do not store. Call audio. Elizabeth AI keeps no audio files of calls; the audio travels from Twilio to xAI in real time and never reaches our server. On the current voice path we also hold no full transcript (section 02).

Who is in the system today. No real patient. The only practice in the system is our own internal demo, whose patient records are fictional apart from our owner’s own test record, and its calls come from our own testing: our owner’s phone, synthetic test callers and fixture numbers, plus a few stray calls to the demo line. Every text message has gone to our owner or to test numbers.

Retention today.

• No patient record, transcript, summary, text message, reading, staff message or audit row is deleted automatically; they are kept until we delete them by hand. Our oldest records date from March 2026. (Housekeeping jobs do remove expired sign-in sessions and expired one-time connection tokens.)
• A daily job is meant to delete local call-audio and trace files older than 90 days. Because we keep no such files, it has never had anything to delete.
• There is no per-practice retention setting and no retention control in the dashboard. A practice may ask us in writing for earlier deletion of specific records; we do that by hand and confirm in writing.
• Full copies of the database exist as manual backups on the same server, including an archive from the August 2026 move to Google Cloud, and as a development copy from before that move on the company’s development computer. None is pruned on a schedule. Application logs roll over by size, so older entries are eventually discarded, and web-server access logs are kept for 14 days.
• Our vendors keep their own copies on their own schedules: Twilio keeps call and message records, and xAI keeps transcripts, until the pending agreements and zero-data-retention configuration change that.

What we never do. We do not sell PHI, and we do not use patient data to train or fine-tune models. Datasets we assembled in May 2026 for model fine-tuning remain on the server; they predate any real patient and contain only test data. Whether our voice vendor may use call content for its own training is not yet settled by contract; that is one purpose of the pending BAA and zero-data-retention configuration.

05Return and destruction at termination

When the agreement ends, the BAA requires us to return or destroy your PHI, or to extend its protections to whatever cannot feasibly be destroyed. How that works today:

• Return. On request we produce a JSON export of your practice’s records (patients, calls, appointments, text messages, consents, refill requests, care gaps, settings and billing history). It is run by our team, not self-service. As of September 29, 2026 it covers every table our deletion process deletes or scrubs, including patient-reported readings, staff messages, outbound-call consent and dial records, and call telemetry.
• Destruction. Our Terms of Service commit us to keep a practice’s data for 90 days after termination, for export and final billing, and then to delete its PHI from the production database by a process run by our team. That process is a sweep with a 90-day default. It is not automatic, it has never been run because no practice has ever cancelled, and it is still being corrected: the rules for which records it deletes and which it keeps (consent records, for example) are not final, so it will not be used until they are. Billing and usage records are kept with patient identifiers removed, and audit rows are kept.
• What cancelling does. Once the account is marked cancelled, service stops automatically at the three points where PHI could otherwise still enter: a call to the practice’s Elizabeth number is refused before it is answered — the caller hears the carrier’s not-in-service message, no AI session starts, the caller’s voice never reaches our voice vendor, and no conversation record or transcript is created (our hourly usage reconciliation still logs the attempt, with the caller’s number, as a usage record that is kept with the number removed after deletion); a text to that number is not stored or answered unless it is STOP or HELP, which are still honored; and staff sign-in is refused, with any open session ended at its next request. Outbound campaign calls are no longer placed. Still done by hand: releasing or porting the number, and turning off reminder texts for appointments that remain on the practice’s schedule, which cancellation does not stop.
• Consent records. How long records of text-message and call consent are kept after termination has not yet been fixed.
• Copies outside our database. Twilio call and message records, xAI transcripts, server logs, database backups and the development copy are not covered by the sweep and are handled separately (section 04).

06Breach notification

What the law requires of us. As a business associate we must report to your practice any breach of unsecured PHI without unreasonable delay and no later than 60 days after discovery (45 CFR § 164.410), and any use or disclosure of PHI the BAA does not permit and any security incident, as the BAA requires (45 CFR § 164.504(e)). Your practice, as the covered entity, notifies affected individuals, the Department of Health and Human Services and, where required, the media. Because we do not encrypt PHI at rest (section 03), we would treat a loss of our database as a breach of unsecured PHI.

What our BAA commits us to. The current BAA template sets a shorter contractual limit: notice to your practice without unreasonable delay and no later than 72 hours after discovery, with what is known at the time — who is affected, what happened, the types of PHI involved, steps individuals can take, and what we are doing to investigate, contain and prevent recurrence — supplemented as the investigation proceeds. An earlier version of the template, generated in April 2026 and still stored in our system, says 24 hours; one number will be fixed, and stated here, before any practice signs.

What exists today. A written incident-response and breach-notification procedure does not yet exist. It is on the pre-launch list, and this page will say when it does.

Texas residents. Texas law separately requires us, as the holder of data your practice owns, to notify your practice immediately on discovering a breach of computerized sensitive personal information; your practice then notifies affected individuals and, when 250 or more Texas residents are affected, the Texas Attorney General, on the deadlines in section 07.

Reporting a concern. If you believe patient information handled by Elizabeth AI has been exposed, email [email protected] or [email protected] with URGENT in the subject line.

07Texas law

Elizabeth AI Receptionist LLC is a Texas limited liability company (Secretary of State file 0806749766) based in Dickinson, Texas. Texas’s Medical Records Privacy Act (Health & Safety Code chapter 181, as amended by HB 300) defines “covered entity” more broadly than HIPAA does and, as we read it, reaches any business that assembles, stores or transmits PHI, so it applies to us directly and not only through our practices. We are not lawyers, this page is not legal advice, and these obligations have not yet been reviewed by an attorney on our behalf. As we understand them:

• No sale of PHI (§ 181.153). We do not sell PHI.
• Electronic disclosure (§ 181.154). Outside treatment, payment and health-care operations, electronic disclosure of PHI needs the patient’s authorization. Our disclosures to the vendors in section 02 are made to perform your practice’s treatment and operations.
• Workforce training (§ 181.101). Covered entities must train employees on state and federal PHI law within 90 days of hire and at least every two years, and keep records. Status: the company is operated by its sole member, and no training records exist yet.
• Breach notification (Business & Commerce Code § 521.053). A business that holds computerized sensitive personal information it does not own must notify the owner immediately on discovering a breach; the owner must notify affected individuals as quickly as possible and no later than 60 days after determining that a breach occurred, and the Texas Attorney General within 30 days when 250 or more Texas residents are affected. For a practice’s PHI we are the holder and your practice is the owner.
• Patient access (§ 181.102). A provider that keeps electronic records must give a patient a copy within 15 business days of a written request. Requests from patients go to your practice; the BAA obliges us to make the records we hold available so you can answer in time.
• AI disclosure (Texas Responsible Artificial Intelligence Governance Act, in force since 1 January 2026). A provider of health-care services that uses an AI system in relation to those services must tell the patient. As we read it, that duty is your practice’s, and we must give you a way to meet it on every call. Status: Elizabeth introduces herself by name and names the practice, but the scripted opening of our outbound calls does not yet say the caller is speaking with an AI system, and we have not yet verified the wording of the inbound greeting, which is configured on our voice vendor’s platform. A clear disclosure on every call is on the pre-launch list.

08Compliance status

One list, so nothing above has to be pieced together. When any line changes, we update this page and its date.

• Practice BAA template — drafted; not yet reviewed by an attorney; no practice has signed it.
• Subprocessor BAAs — none executed (xAI, Twilio, Google Cloud, Cloudflare, Microsoft).
• HIPAA Security Risk Analysis — not started.
• Written incident-response and breach-notification procedures — not written.
• Workforce training program and records — none yet.
• Independent vulnerability scan or penetration test — none run.
• Multi-factor authentication — not required by the application.
• Application-level encryption of PHI at rest — not enabled.
• Automatic deletion of records — not running; deletion is manual (section 05).
• Data export for returning a practice’s PHI — exists; run by our team on request, not self-service (section 05).
• AI disclosure in call scripts — not yet added (section 07).
• Technology E&O and cyber-liability insurance — no policy in force; no certificate of insurance can be issued.
• Certifications — none. We hold no SOC 2, HITRUST or other third-party attestation.
• New practice sign-ups — closed until the subprocessor agreements are executed.

09Questions?

If you have questions about anything on this page, or would like a copy of our BAA template or written confirmation of our subprocessor status on a given date, contact us: