Privacy policy.

Elizabeth AI Receptionist LLC answers and places phone calls, sends text messages, and runs a check-in kiosk for medical practices. This policy says what we collect, where it goes, how long we keep it, and which safeguards are in place today. Where something is planned but not yet in effect, we say so rather than imply it. Application-level encryption at rest is not yet enabled on this host.

01Who we are and what this covers

Elizabeth AI Receptionist LLC (“Elizabeth AI”, “we”) is a Texas limited liability company based in Dickinson, Texas. This policy covers three groups of people:

• Patients and callers of a practice that uses Elizabeth — people who call the practice’s Elizabeth line, receive a call or text from it, or use its check-in kiosk. For this information the practice is the HIPAA covered entity and we are its business associate: we act on the practice’s instructions under a Business Associate Agreement (BAA), and the practice remains the custodian of your record.
• Practices and their staff — the clinics that buy the service and the people who sign in to the dashboard.
• Prospects and website visitors — anyone who visits elizabethaireceptionist.com, requests a demo, or sends us a message. For this information we are the responsible party and this policy governs it directly.

Where things stand today. Elizabeth is not yet live with any practice. The only practice data in the system belongs to our own internal demo practice, whose patients are fictional, and to test accounts we created ourselves. Nearly every call and text on record was placed by or to our owner, to test numbers, or by our automated testing tools; a few short calls and text replies have come from numbers we do not recognise (wrong numbers, for example), and those callers’ numbers and call details are stored like any other call. No real patient record exists in the system. We publish this policy now so that what we promise is on record before the first practice goes live, and we will update it when that changes.

02Information we collect

What we collect depends on who you are.

Patients and callers (on behalf of your practice):

• Call details — the phone number you call from or that the practice has on file for you, the date, time and length of the call, and which practice line was used.
• What is said on the call — your voice is streamed live to our voice-AI vendor so Elizabeth can understand and respond. Our own server never receives the audio, and we do not store call audio. We store a short summary of each call, the requests Elizabeth made to our server during it and their results (for example the name and date of birth used to find your record, a booking, a refill request or a message), and, for outreach calls, Elizabeth’s notes and the readings you reported. We do not store a word-for-word transcript of calls made on the current system; our voice vendor keeps the transcript on its side (section 04). Word-for-word transcripts of calls made on our earlier, self-hosted system (March to August 2026, all test calls) remain in our database.
• Identity and appointment details — your name, date of birth, appointment date, time and provider, and the reason for your visit, used to find your record and to book, change or cancel appointments.
• Refill requests — the medication, your pharmacy’s name, address and phone number, and any notes.
• Messages for staff — your name, a callback number and the message you leave.
• Health readings you report on an outreach call — such as blood pressure, blood sugar, A1c, oxygen level or cholesterol, together with the care item the practice asked us to call you about.
• Kiosk check-in — your name and date of birth to find today’s appointment, and your insurance carrier, member ID and group number if you choose to type them in (the kiosk does not photograph cards).
• Text messaging — your mobile number, the messages we send you and any you send back (including STOP, START, YES and HELP), and your consent record: the date and time, where you opted in, the exact consent wording shown to you (or, for a YES opt-in, the reply you sent). The consent record itself does not hold an IP address or browser details; a demo request records those with the request (see below), and the kiosk records neither.

All of the above is treated as Protected Health Information (PHI) under HIPAA.

Practice staff and clients:

• Account details — name, work email, username, a hashed password, your role, and sign-in sessions. If you sign in with Google or Microsoft, that provider gives us your name, email address and account identifier; we keep only those.
• Practice configuration — practice name, hours, providers, phone numbers, greeting, notification addresses and alert phone numbers.
• EHR credentials and per-practice API keys your practice gives us, stored encrypted (AES-256-GCM).
• Billing — your billing contact and payment card are entered with Stripe, our payment processor. We store Stripe’s customer and subscription identifiers and the invoice records Stripe sends us, never card numbers.
• Usage records — call minutes, text counts and costs per billing period.

Prospects and website visitors:

• Demo requests — name, work email, phone, practice name, notes, the time slot you chose, and the IP address and browser you used.
• Contact form — name, practice, email, phone and your message.
• Server logs — IP address, pages requested, browser type and timestamps, kept by our web server and by Cloudflare, which fronts our site.

03How we use information

• To run the service for your practice — answer and place calls, book, change or cancel appointments, take refill requests and messages, send appointment texts, and record the outcome of outreach calls.
• To notify the practice — call summaries, outcome cards and alerts go to the practice’s dashboard, its Microsoft Teams channel, its email and its alert phone. Teams cards and emails can include a patient’s name, the outcome and any reading reported; text alerts identify the patient by initials and the last four digits of the phone number, or by call reference only.
• To write to your practice’s EHR when the practice connects one. No practice EHR is connected today; our Epic, athenahealth and Oracle Health integrations are registered against vendor sandboxes only. eClinicalWorks is not an available integration.
• To bill the practice — minutes and texts are counted per billing period. Nothing about a patient is sent to Stripe.
• To keep the service working and improve it — we review call transcripts, outcomes, errors and timing to fix problems and refine Elizabeth’s scripts. We do not currently run a formal de-identification step, so this review is done by us as the practice’s business associate, limited to what the task needs.
• To meet legal obligations, including HIPAA, Texas health-privacy law and the wireless carriers’ messaging rules.

We do not use your information for advertising, and we do not sell it.

04Who we share it with

We share information only as needed to deliver the service, and we name every company involved below. None of the vendors below that handles patient information has signed a Business Associate Agreement with us yet. That is one reason no practice is live: we will not route a real patient’s call until the agreements with every vendor that will handle patient information are signed. Ask us and we will confirm the status in writing on the day you ask; the HIPAA page carries the current status.

• Your practice’s authorized staff — everything described in section 02, through the dashboard, notifications and reports.
• xAI (Grok Voice) — the voice AI. It receives the live call audio and the conversation on every inbound and outbound call and holds the only word-for-word transcript of calls made on the current system, on its side (we have observed roughly 30 days in its console). Neither a BAA nor a zero-data-retention configuration is in place with xAI yet; until both are, we do not send any real patient’s information to it.
• Twilio — telephone carrier and text-message delivery. It receives phone numbers, call routing details and every text we send or receive (which can include a name, appointment date, time and provider), and keeps its own call logs and message records. We do not turn on Twilio call recording. No BAA yet; Twilio requires a paid account edition for one, which we have not purchased.
• Google Cloud — hosts our server and database on one virtual machine in Iowa, USA. Google’s BAA has not been accepted yet.
• Google Maps — when a caller names a pharmacy, we look up its address with Google’s Maps service. The search text (the pharmacy name and area) goes to Google; the caller’s name and number do not.
• Cloudflare — sits in front of our website, API and vendor webhooks and terminates the encrypted connection, so it can see that traffic in the clear at its edge. No BAA.
• Microsoft (Teams, Power Automate and our company email) — delivers staff notifications and email, and hosts our own mailboxes, so email you send to our addresses is stored there. Cards and emails can include patient names, outcomes and readings. No BAA.
• Stripe — billing. Receives the practice’s billing contact and card details; never patient information.
• Google and Microsoft sign-in — optional single sign-on for staff. They learn only that a staff member signed in to Elizabeth.
• SignNow — electronic signature of the practice agreements at onboarding (not yet used by any practice, as sign-ups are closed). It receives the signer’s name and email address and the signed documents; never patient information.
• Your practice’s EHR — only when your practice connects one. None is connected today.
• Formerly used, not in the live call path — Amazon Transcribe and S3 (call analytics until April 2026) and Telnyx (our telephone carrier until August 2026, which may still hold call records from that period and two test-call recordings). They handled only the test and staff data described in section 01. We have not yet confirmed that those vendor-held copies are deleted.
• When the law requires it — a subpoena, court order or regulator. We will tell the practice unless the law forbids it.

The BAA requires us to tell each practice before we add a vendor that will handle patient information, and we will update this list when it changes. We do not sell or share personal information for advertising.

05Data security

This section describes what is in place today and what is not.

• In transit. Browsers and the kiosk connect to Cloudflare over HTTPS, and Cloudflare connects to our server over TLS 1.2 or 1.3. Today Cloudflare’s edge still accepts connections from very old browsers using TLS 1.0 and 1.1; we intend to raise the minimum to TLS 1.2, and this sentence will change when we do. Calls travel from the phone network to Twilio the way any phone call does, and from Twilio to our voice vendor over SIP with TLS-protected signalling; we have not verified that the audio stream itself is encrypted.
• At rest. Application-level encryption at rest is not yet enabled on this host. Our database is a plain SQLite file on a Google Cloud virtual-machine disk; the only data we encrypt in the application is the credential store (a practice’s EHR credentials and per-practice API keys, AES-256-GCM). Google encrypts its disks by default with Google-managed keys, but we have not yet obtained that assurance in writing under a BAA. Database backups are kept on the same server and are not encrypted by the application. A development copy of the database, holding the same test data, is also kept on our owner’s computer.
• Access. Only Cloudflare’s network can reach our web server, and administrative access is by SSH key only. Staff sign in with a password or optional Google/Microsoft single sign-on and are limited by role. The product does not yet require multi-factor authentication.
• Audit logging. The requests Elizabeth makes to our server during a call — identity checks, slot lookups, bookings, refill requests, messages — are written to an audit log. The outcome she records at the end of an outreach call is stored in the call record but not yet in the audit log. Staff sign-ins and record views are not yet logged; we say this because the phrase “audit logging” on its own would overstate it.
• Logs. Application logs mask phone numbers, email addresses, dates of birth and similar patterns before they are written. Web-server access logs still contain IP addresses.
• Not done yet. A HIPAA Security Risk Analysis, a written incident-response plan and application-level encryption of PHI at rest are on our pre-launch list and are not in place today.

06Data retention & deletion

Today, nothing we hold is deleted on a retention schedule. We would rather say that plainly than describe a schedule that does not run.

• Call audio — never stored by us. Our voice vendor keeps the transcript on its side under its own retention. (A daily job that would delete local call-audio and trace files older than 90 days has never had a file to delete, because we keep none.)
• Call summaries, the details Elizabeth records on calls, older word-for-word transcripts, text-message logs, consent records, readings, refill requests, staff messages, audit logs and call telemetry — kept in our database until we delete them. No automatic purge runs today, and there is no retention setting a practice can change in the dashboard. Data from our own testing dates back to March 2026. (Expired sign-in sessions are cleared and care-gap findings are recomputed on each scan; neither is a retention control.)
• Backups — full database backups are kept on the server and are not yet pruned on a schedule.
• Vendor copies — xAI, Twilio, Microsoft and Cloudflare keep their own logs and records on their own schedules, under their terms and, once signed, their BAAs.
• When a practice’s agreement ends — the BAA requires us to return or destroy its PHI, or to keep protecting it where destruction is not feasible. We have a deletion routine for this that removes the practice’s patient data and keeps only billing records and the audit trail. It is run by hand, it defaults to 90 days after the end date, and it has not yet been run for any practice; we are still correcting it. A practice can ask us in writing to delete its data sooner, and we will do it by hand. From the moment a practice’s account is closed, its Elizabeth number no longer answers calls (callers hear a not-in-service message; no AI session starts and no conversation record is made), texts to that number other than STOP and HELP are not stored or answered, and its staff can no longer sign in; reminder texts for appointments still on its schedule are not stopped automatically, and end when its data is deleted or when we turn them off by hand.
• Consent records — we intend to keep proof of text-message consent and opt-outs for as long as the law and the carriers require, even after other data is deleted. We have not yet fixed that period.
• Website and prospect data — demo requests, contact messages and server logs are kept until we delete them. Email us to have yours removed.

Where this policy, our Terms of Service and a practice’s BAA differ on timing, the BAA controls.

07Your rights

Patients. Your HIPAA rights — to see and get a copy of your records, to ask for corrections, to an accounting of disclosures, and to complain — run to your practice, which holds your record. Ask the practice; we support it in answering within HIPAA’s timelines, and if you contact us directly we will pass your request to your practice. You can stop text messages at any time by replying STOP, and you can stop outreach calls by telling Elizabeth during an outreach call or by telling the practice, which will pass it to us.

Practice staff and clients. You may ask to see, correct or delete your account data, and a practice may ask for a copy of its data, at any time. Email us at the address in section 14.

Prospects and visitors. You may ask us to see, correct or delete your demo request or message. If a state privacy law, such as Texas’s, gives you additional rights over your personal information, email us and we will honor them where they apply.

We will not treat you differently for exercising any of these rights. You may also complain to the U.S. Department of Health and Human Services Office for Civil Rights or to the Texas Attorney General.

08HIPAA & Texas law

Our role. For patient information, the practice is the covered entity and Elizabeth AI Receptionist LLC is its business associate. We sign a Business Associate Agreement with every practice before it goes live; no practice is live yet, so no customer BAA is in effect today. The BAA limits our use and disclosure of PHI to providing the service; requires safeguards; requires us to tell the practice of any unauthorized use or disclosure, security incident or breach without unreasonable delay and within the fixed deadline stated in the BAA (the template is still being finalised: our current draft says 72 hours after discovery, while an earlier version still on file says 24 hours, and one number will be fixed, and stated here, before any practice signs); requires written agreements with our own subcontractors (in progress, not yet executed with every vendor); and requires return or destruction of PHI when the agreement ends.

Texas. Texas Health & Safety Code chapter 181 (the Texas Medical Records Privacy Act) treats a company like ours that stores or transmits PHI as a covered entity under state law. Among other things it forbids selling PHI, restricts marketing uses of it, and requires staff training on health-privacy law. Elizabeth AI is a one-person company today, and we have no formal training program on record yet. Texas law (Business & Commerce Code § 521.053) also requires us to notify the practice immediately when we discover a breach of computerized sensitive data we hold for it; the practice, as owner of the data, notifies affected individuals and, where required, the Texas Attorney General.

No certification. HIPAA has no certification, and no vendor can be certified under it. We do not describe ourselves as certified, audited or compliant; we describe the controls that are in place and the ones that are not. We are not lawyers: this section states our own understanding of these obligations, and we will have it reviewed by a licensed attorney before any practice goes live.

09AI & voice calls

• Elizabeth is an automated AI system built on xAI’s Grok Voice. Audio is streamed live to xAI, which produces the words Elizabeth speaks. We do not record the audio; a transcript is kept as described in section 02.
• Disclosure. Texas law requires health-care providers to tell patients when AI is used in their care, and federal rules require automated calls to identify who is calling. Elizabeth introduces herself by name and names the practice. The scripted opening of an outbound call does not yet say plainly that she is an AI system, and as last recorded the inbound greeting describes her only as “your virtual assistant”; we are adding plain AI wording to both before any practice goes live, and the practice is responsible for its own patient disclosures.
• Not medical advice; not for emergencies. Elizabeth does not give medical advice or interpret results. Her instructions are to tell anyone who describes an emergency or severe symptoms to hang up and call 9-1-1; that is a safeguard, not an emergency service. Any reading a patient reports is passed to the practice for a clinician to review; Elizabeth does not diagnose or make clinical decisions.
• Human oversight. The practice’s staff review call summaries and outcomes and act on them.
• Training. We do not use patient calls to train AI models, and we have not fine-tuned any model. In May 2026, on our earlier system, we assembled a training dataset from our own test calls; no model has been trained on it, and it contains no real patient’s information. Our voice vendor’s own training and retention terms are not yet settled by contract; until they are, no real patient’s data goes to it.
• Outbound calls are placed only for a practice, to patients on its list, for reasons the practice chose (for example an overdue blood-pressure follow-up). Each call is scripted to confirm it has reached the right person before any health detail is discussed; that is a scripted safeguard, not a guarantee. If you say you do not want these calls, Elizabeth records a permanent do-not-call for your number, and you can also tell the practice, which will pass it to us.
• Reminders are sent by text only. We do not place automated reminder calls.

10Kiosk practices

The check-in kiosk is a web page on the practice’s tablet. A patient types their name and date of birth (or, if the practice turns on the day’s roster, taps their name and then enters their date of birth); the kiosk shows today’s matching appointment, confirms check-in, may ask for insurance details if none are on file, and shows the optional text-message consent checkbox.

No patient information is stored in the tablet’s browser between patients, and the kiosk returns to its start screen after 90 seconds of inactivity. Check-in records, insurance details and consent are stored on our server in the practice’s account; they are not sent to an EHR unless the practice connects one. Staff leave kiosk mode with their own username and password.

11Cookies, fonts & analytics

• Cookies. Every page sets a csrf_token cookie that protects forms and contains no personal information. Signed-in staff also get a session_token cookie (HttpOnly; it expires after eight hours or when you sign out), and Google or Microsoft sign-in sets a short-lived state cookie during the sign-in itself. We set no advertising or tracking cookies.
• Fonts. Our pages, including the kiosk, load fonts from Google Fonts, so Google’s servers receive your IP address and browser details when a page loads.
• Cloudflare. All traffic to our site passes through Cloudflare, which logs requests (IP address and URL) to operate its service.
• Analytics. We run no third-party analytics, pixels or ad trackers on any page, including patient-facing ones.

12Children's privacy

The service is operated for healthcare practices, which serve patients of all ages under existing guardianship and consent laws. We do not knowingly collect information from children other than through a practice’s own patient records, and our website and demo form are intended for adults.

13Policy changes

We will email each practice’s primary contact at least 30 days before a material change to this policy takes effect, with a summary of what changed, and we will update the dates at the top of this page. A change that only adds a safeguard or corrects the description of what we already do may take effect when it is posted. Continued use after the effective date is acceptance of the updated policy.

14Contact us

For privacy questions or requests, email [email protected] or [email protected]. To report a suspected security incident, put URGENT in the subject line; we will acknowledge it within one business day and follow the notification timelines in section 08.

15SMS & text messaging

How we get consent. Elizabeth AI Receptionist LLC sends text messages only to people who have agreed to receive them, in one of these ways — and only these:

• A checkbox that loads unchecked on a practice’s check-in kiosk (patients) or on our demo request form at https://elizabethaireceptionist.com/book-demo (practice staff). The box is never pre-ticked, and typing a phone number is not consent. The exact checkbox wording, with screenshots, is at https://elizabethaireceptionist.com/sms-consent.
• A YES reply. When an appointment is booked for you — by Elizabeth on a call, or by the practice’s staff in its dashboard — we send one text: “[Practice]: Reply YES to get appointment texts. Msg & data rates may apply. Reply STOP to opt out, HELP for help.” Replying YES opts you in. If you do not reply, you get no reminders; the invitation may be sent again if another appointment is booked for you later and you still have not replied.
• Re-subscribing after STOP. Replying START, UNSTOP or YES to any message opts you back in. A later checkbox does not: a number that has opted out is never re-subscribed by a kiosk or web checkbox.

We never buy or import opt-in lists. Texts are sent from a number registered to Elizabeth AI Receptionist LLC under the U.S. carriers’ A2P 10DLC program, on behalf of your practice, and each message to a patient names the practice.

Consent is not a condition of purchase or care. Checking the box, or replying YES, is optional. A visitor who leaves the box unchecked can still book a demo or become a customer. A patient who declines is checked in the same way and receives the same care. Nothing about the service is withheld for declining texts.

• What we send — to patients: the opt-in invitation and its confirmation; appointment confirmations, reminders ahead of the day and on the day, and cancellation or rescheduling notices; prescription-refill status updates; and, if your practice runs outreach, a message about care your clinician has recommended or a follow-up text if our outreach calls could not reach you. To practice staff: alerts about calls that need attention. To prospects who ticked the box: messages about the demo you requested (today, demo confirmations go by email, and we have not yet sent demo texts). We do not send unrelated marketing to numbers collected this way.
• When we send — reminders and outreach texts go out only between 8 am and 9 pm, measured in U.S. Central Time today (the hours themselves can be set per practice; a per-practice time zone is not yet applied). Texts that follow something you just did — the YES invitation after a booking, and confirmations of bookings, cancellations, reschedules and refill requests — are sent right away.
• Message frequency — varies with how many appointments you have scheduled; there is no fixed cadence.
• Cost — message and data rates may apply. We do not charge for messages; your mobile carrier may.
• Stopping — reply STOP to any message to opt out. Reply HELP for a menu with the practice’s phone number, or email [email protected] or [email protected]. An opt-out is honored immediately, by our carrier and by us. Telling Elizabeth during an outreach call that you do not want to be contacted stops that practice’s outreach calls and the follow-up text those calls would otherwise trigger; on the current voice path it does not by itself stop appointment texts, so reply STOP to any text, or tell your practice, which can record an opt-out (or ask us to) that stops calls and texts together.
• Carrier liability — mobile carriers are not liable for delayed or undelivered messages.

What we store as proof of consent is the number, your name where we have it, the date and time, where the opt-in happened (your practice’s check-in kiosk, our demo request form, or a YES reply), the exact wording shown to you or the reply you sent. The consent record itself does not hold an IP address or browser details (a demo request records those with the request; the kiosk records neither). The full program terms are in our Terms of Service.