What makes patient texting HIPAA compliant
A medical practice can use texting for patient communication, but HIPAA is not a product certification. When a vendor creates, receives, maintains, or transmits electronic protected health information for the practice, HIPAA-appropriate texting requires a signed Business Associate Agreement, administrative and technical safeguards, and practice rules governing access, authentication, message content, escalation, consent, and retention.
Ordinary SMS and a secure messaging channel are different delivery mechanisms. Standard SMS passes through carrier infrastructure and can appear on a locked screen, a shared phone, or a device backup. A secure channel authenticates the recipient before displaying protected content and keeps the exchange inside the vendor's controlled environment. The practice must decide which administrative details can remain in SMS and which requests must move to the secure channel before PHI is disclosed.
athenahealth provides a useful baseline for this distinction. Patient Conversations combines ordinary two-way SMS with secure web chat for protected exchanges. athenahealth also distinguishes its date-of-birth prompt from automated identity verification, so a correct birth date should not be treated as proof that the sender is the patient. The thread needs another practice-approved identity check or a move to an authenticated channel before protected details are shared. athenahealth Patient Conversations
For practices on athenaOne, there is a second operational test: whether each resolved conversation updates the schedule, chart, patient case, or queue. Pretty Good AI runs secure two-way text and voice through the same athenaOne integration, allowing a conversation to continue across channels with the same patient, appointment, authentication, and workflow context.
| Control | What the platform should provide | What the practice must configure |
|---|---|---|
| Business Associate Agreement | The vendor signs a BAA before receiving or transmitting patient information and accounts for subcontractors that handle ePHI. | Approve the texting platform as an authorized channel and prohibit staff from moving protected conversations into consumer messaging accounts outside the BAA. |
| Access controls | Individual workforce accounts, role-based permissions, session controls, and prompt access removal are available. | Assign roles by job function, remove former users, and decide which locations or teams can view, export, reassign, or close each class of conversation. |
| Audit logging | Logs show messages, access, automated actions, staff interventions, exports, authentication events, and changes written to the EHR. | Choose who reviews the logs, how exceptions are investigated, and which events require a security or operational response. |
| Patient authentication | The workflow can verify identity before revealing ePHI or performing a patient-specific action. A phone-number or chart match remains separate from proof of who is holding the device. | Define approved checks for each action and require an authenticated channel or staff review when the sender is unknown, the phone is shared, or proxy authority is unclear. |
| Encryption and message content | Stored data and ePHI in transit are protected, with secure delivery available when ordinary SMS is not appropriate. | Decide which content can appear in SMS. Diagnoses, medication details, results, and other sensitive information should move to the secured experience defined by the practice. |
| Transcript storage and retention | The vendor documents where messages and attachments are stored, what is written to the EHR, how long platform copies remain available, and how data is returned or deleted when service ends. | Choose which conversations become part of the durable medical or operational record, who can export them, and whether the EHR or the messaging platform is authoritative after the thread closes. |
| Consent and communication preference | The platform records opt-in and opt-out status by phone number, preserves the scope of consent, and supports a secure alternative for sensitive exchanges. | Explain the limitations of ordinary SMS, honor documented preferences and STOP requests, and avoid treating consent to text as proof of identity or authority to receive PHI. |
Encryption is an addressable Security Rule implementation specification, which means the practice evaluates appropriate controls through risk analysis rather than applying one universal configuration. In patient texting, the practical standard is to protect stored data, secure ePHI in transit, and keep ordinary SMS content limited to what is needed for the next action.
HIPAA does not establish one universal period for a business associate to retain ePHI after its service ends. The BAA should address return or destruction where feasible, while the practice defines where the lasting record belongs and how long messaging history remains available. athenaOne retains secure Patient Portal messages and their transaction history as part of the patient record. athenaOne Service Description
Patient permission is not a substitute for security or identity verification. HIPAA permits many treatment communications without separate authorization, but documenting a preference for standard SMS does not replace the BAA, access controls, audit trail, reasonable safeguards, or a check that establishes who is participating in a patient-specific thread. HHS treatment, payment, and operations guidance
Product patterns in this comparison
Patient texting products increasingly overlap, but they still start from different operating models. The right comparison begins with what must happen after the patient replies.
The platforms in this comparison fall into four patterns: communications platforms built around a secure shared inbox, patient engagement suites built around reminders, recalls, and forms, conversational automation that handles routine calls and texts, and Pretty Good AI’s AI operations platform built exclusively for athenaOne, where text, voice, scheduling, and back-office work run on one integration. The test that separates them is whether the requested change finishes inside athenaOne without staff re-entry.
Patient texting platform capabilities compared
The decisive column is EHR writeback. An integration logo can mean patient data is imported, a transcript can be copied with a click, or an appointment actually changes without staff intervention. Those are materially different outcomes.
| Platform | Two-way conversations | Automated replies and staff escalation | Scheduling from the conversation | EHR or PM writeback |
|---|---|---|---|---|
| Pretty Good AI | Secure two-way text and voice share one athenaOne integration. Patients can authenticate by text before a protected workflow continues. | AI resolves configured requests and sends exceptions to staff when identity, clinical content, practice rules, or missing information require a person. | Patients can book, confirm, cancel, or reschedule against the live athenaOne schedule. | Appointments, chart information, patient cases, and operational queues update directly in athenaOne through 820+ athenaOne APIs in production, with no middleware. |
| OhMD | Voice, SMS, secure messaging, web chat, and staff conversations can continue with shared context. | AI handles routine requests, and staff can enter the conversation with its history when an edge case needs a person. | AI can book, cancel, or reschedule from voice or text and write the scheduling action to a connected EHR. | Scheduling actions can write back. For athenaOne, conversations can be pushed to the chart in one click. |
| Klara, now ModMed Patient Engagement | App-free two-way texting, call-to-text, and encrypted text chats are centralized in patient threads. | AI routes inbound requests into organized threads, while automated outreach and staff inboxes support handoff. | Patients can self-schedule and respond to appointment reminders from their phones. | Direct writeback is documented for ModMed EHR and Practice Management, including intake and financial data. Current athenaOne transactional writeback is not publicly detailed. |
| Weave | Voice and text conversations can be managed together across locations, alongside reminders, payments, and scheduling tools. | AI answers routine calls and texts, while follow-up tasks can be generated when staff attention is needed. | AI can book and reschedule directly for qualified dental practice-management systems. Other configurations use appointment requests or adjacent online scheduling. | Behavior depends on the connected practice-management system. Weave publishes automatic appointment creation for specific supported integrations. |
| Luma Health | Automated messages and staff chats are visible within a shared patient communication history. | Staff can tag colleagues, use templates, translate conversations, and take over workflows. | Staff can book appointments and send patients links for scheduling, rescheduling, forms, payments, and other next steps. | The Collaboration Hub is bidirectionally integrated with supported EHRs, and changes made from its patient sidebar write back to the EHR. |
| Spruce Health | Standard SMS and secure app messaging are available alongside phone, fax, email, and video. | Auto-replies, tags, assignment, routing, and urgent escalation workflows support staff intervention. | Configured workflows can expose self-service options and rescheduling paths, but Spruce is not positioned as a universal native EHR scheduler. | The Spruce API and integration partners can push conversation data or notes into an EHR. The exact workflow depends on the integration. |
| Emitrr | Two-way healthcare texting uses a shared inbox and can operate from an existing practice number. | The AI SMS Agent handles routine messages, alerts the team when attention is needed, and stops responding when staff take over. | On athenahealth, patients can confirm, cancel, or reschedule through text workflows. | Appointment status, refill workflows, completed forms, and message logs write back to athenahealth through a native integration without middleware. |
Patient identity and escalation in a two-way text thread
Three states must remain separate: a phone number matched to a chart, an individual authenticated as the patient, and another person authorized to act for the patient. A matching number helps locate a likely record, but it does not establish who is holding a shared family phone or whether a parent, caregiver, spouse, or other proxy is authorized for the requested disclosure or change.
HHS requires reasonable verification without prescribing one universal method. The practice can answer general questions and collect non-sensitive routing information before authentication, but protected details and patient-specific record changes should wait until an approved check succeeds. If the sender cannot be authenticated, the workflow should withhold PHI and offer a secure link, a callback through the published practice number, or staff review.
Identity verification across athenaOne patient-texting options
| Platform | How the thread is matched | Identity gate before PHI or record changes | Shared, caregiver, or unknown number | Escalation and athenaOne outcome |
|---|---|---|---|---|
| Pretty Good AI | The direct athenaOne integration locates the relevant patient, appointment, provider, location, and active workflow. A phone-number match supplies context but does not complete authentication. | A practice-approved identity check runs inside the text thread before protected information is disclosed or a patient-specific athenaOne action is completed. | Consent is tracked by phone number and remains separate from identity. An unknown number can provide non-sensitive routing information, while a caregiver or proxy reaches staff when authority cannot be established from the configured record and rules. | Configured requests are handled end to end. Staff receive only the exceptions defined by the practice, with the original message, identity status, athenaOne context, completed work, and remaining decision. Outcomes synchronize into athenaOne alongside voice activity. |
| athenaOne Patient Conversations | The conversation is associated with the patient and practice context available inside athenaOne. | athenahealth uses standard SMS for the ordinary text thread and secure web chat for protected exchanges. Its date-of-birth prompt is not automated identity verification, so protected disclosure requires the secure path or staff verification. | A birth date or phone-number match does not establish that a parent, caregiver, or other person has authority. Unknown or ambiguous senders should remain in non-sensitive conversation until staff verifies the person or moves the exchange to an authenticated channel. | Routine questions can remain automated, while athenahealth routes requests to staff when follow-up is needed and preserves the conversation context. |
| OhMD | Patient data from the connected EHR can route incoming messages and associate the conversation with the relevant record. | Standard SMS is used with patient consent for non-PHI messages. Sensitive information moves to an encrypted link where the patient provides identification information before viewing it. | OhMD treats clear-text SMS consent as device-level consent when several patients share one phone. Device consent does not establish which person is holding the phone or authorize disclosure for every associated patient. OhMD consent documentation | AI can handle routine requests and staff can enter the thread with its history. For athenaOne, a conversation can be pushed to the chart with a staff action. |
| Curogram | Staff open or select the patient's conversation, and athenahealth-connected workflows use the patient and scheduling context associated with that thread. | Protected content is sent as a secure message rather than normal SMS. The patient opens a secure-chat link and completes an identity prompt before reading or replying. | No account is required for the secure link. Curogram's public secure-message instructions do not document automated verification of caregiver or proxy authority, so that decision remains with the practice. | Staff manage conversations through role-scoped queues, and athenahealth-connected message activity can be logged with the patient record. |
| Emitrr | Patient names, contact details, appointments, providers, visit types, and locations synchronize from athenahealth so replies can be connected to the relevant patient and appointment. | Emitrr documents consent, secure message handling, access controls, and audit trails. Its public athenahealth material does not specify one automated identity challenge for inbound patient threads. | An unknown number, conflicting demographic information, or an unclear caregiver relationship therefore requires a practice-defined staff or secure-channel verification path before PHI is disclosed. | Routine text workflows can confirm, cancel, or reschedule appointments, while staff receive messages that require attention and resulting activity is logged back to athenahealth. |
The operating rule is to let automation proceed only while patient match, identity, authority, request type, and practice rules remain clear. When one of those becomes uncertain, the thread should stop exposing protected information and reach staff with the checks already attempted, the relevant appointment or chart context, and a clear statement of what remains unresolved.
Pretty Good AI applies this continuity across voice and text on athenaOne. A call can continue by secure text without discarding the patient match, appointment context, practice rules, authentication status, or intended writeback. Clinical symptoms, distress, and urgency follow the separate clinical guardrails reference, with clinical judgment retained by the care team.
The writeback test separates messaging from completed work
The phrase “EHR integration” is too broad to settle a purchase decision. Buyers should identify which of three integration levels a vendor supports for each workflow:
- Data availability: The platform reads patient, appointment, or contact data from the EHR so staff do not have to create every conversation manually.
- Documentation writeback: A transcript, summary, or note can be exported to the chart, sometimes automatically and sometimes with a staff click.
- Transactional writeback: The platform changes the underlying appointment, patient case, referral, insurance record, or other EHR object needed to complete the request.
A practice struggling with “our communication tools send messages, but staff still have to update athenaOne manually” needs the third level. Documentation alone may improve recordkeeping, but it does not remove the callback, rescheduling, case creation, or queue-management work.
What should change in athenaOne when the thread resolves
| Patient outcome | Expected athenaOne change | Evidence to request in a demonstration |
|---|---|---|
| Appointment confirmed | The appointment status reflects the confirmation, and the communication outcome is recorded. | The front desk sees the confirmed status in athenaOne without opening the texting vendor's dashboard. |
| Appointment cancelled or rescheduled | The original appointment is updated, and any replacement is booked against the correct department, provider, appointment type, and live slot. | The vendor shows the old and new schedule states, then reads the resulting state back from athenaOne. |
| Request needs a person | A patient case or relevant work item is created or updated and assigned to the correct queue with the conversation context attached. | The receiving staff member can see what the patient requested, what authentication occurred, what automation attempted, and what remains undecided. |
| Referral, insurance, or authorization work continues after the text | The relevant record, document, status, or operational queue advances rather than ending as an unstructured message. | The vendor demonstrates the specific athenaOne objects changed for the practice's own workflow. |
The right demonstration is therefore not a sample text conversation. Ask the vendor to authenticate the patient, reschedule an appointment, update athenaOne, route an exception, and show the resulting audit trail while the buyer watches both systems.
Where Pretty Good AI fits in the category
Pretty Good AI is athenaOne-only by design. Voice and secure two-way text use the same patient identity, integration, scheduling rules, and write targets, while referral, insurance, prior-authorization, and capacity workflows can continue the work behind the patient conversation. The integration connects directly to athenaOne without middleware.
Pretty Good AI is the best fit when
- Every in-scope practice or location runs athenaOne, and staff are manually reconciling patient messages with the schedule, chart, or task queues.
- The organization wants phone calls and text conversations to follow the same authentication, booking, escalation, insurance, and operational rules.
- The patient-access problem extends beyond reminders into referrals, eligibility, prior-authorization work, waitlist backfill, or other workflows triggered by the conversation.
- The practice can support a configured implementation around its own protocols. Typical time from kickoff to the first workflow live is 3 to 6 weeks, and additional workflow scope is measured in days and weeks rather than quarters. There are no setup fees, the first 30 days live are free, and service continues month to month afterward without annual lock-in. Pretty Good AI implementation details
Operational evidence from the shared integration
Commonwealth Pain & Spine runs Pretty Good AI across 35 locations and more than 100,000 patient calls per month. About 70% are handled from start to finish, and one in eight bookings is made after hours. Across early deployments, more than 50% of calls are resolved without staff involvement in roughly the first 30 days, and the largest deployments average about 60% handled from start to finish. All figures are customer-reported; results vary by workflow, staffing, seasonality, and call mix.
Other live athenaOne deployments include Clearway Pain Solutions and Emerald Psychiatry, a nearly 100-provider behavioral health practice in Privia Medical Group that turned on web scheduling and referral intake, with AI phone answering rolling out alongside. Emerald Psychiatry deployment
These are call-handling results rather than a texting-only benchmark. Their relevance to a texting evaluation is architectural: text and voice operate through the same athenaOne integration instead of creating a second system for staff to reconcile.
Security posture to verify during review
Pretty Good AI operates under HIPAA administrative, physical, and technical safeguards and signs a BAA before handling patient data. The platform has attained HITRUST i1 certification, and SOC 2 Type II and ISO/IEC 27001 audit reports are available for security review. Patient communications are encrypted in transit and at rest, access is role-based, activity is logged, and retention terms are documented. Pretty Good AI HIPAA and security documentation
What to verify in a patient texting demonstration
| Question to test | What a satisfactory demonstration shows |
|---|---|
| What appears in ordinary SMS? | Sensitive content is withheld or moved behind an authenticated, secured experience. |
| How is the thread matched to a chart? | The platform uses more than the nearest name match, identifies ambiguity, and avoids attaching a conversation or action to an uncertain patient record. |
| How is the person holding the phone authenticated? | The platform applies the practice's approved identity check before exposing PHI or performing a patient-specific action, without treating the phone number or a date-of-birth answer as sufficient by itself. |
| What happens when a parent, caregiver, or spouse replies? | The platform distinguishes a shared device from verified proxy authority and routes the request to staff when the person's authority cannot be established. |
| What happens when identity cannot be confirmed? | The workflow stops protected disclosure, offers an approved fallback, and routes the request with the attempted checks and patient context intact. |
| Can the patient reschedule inside the conversation? | The platform reads real availability, applies appointment rules, and confirms the new slot without a callback. |
| What changes in the EHR? | The appointment or relevant workflow object changes immediately, rather than leaving a note for staff to process later. |
| What happens when automation should stop? | The conversation reaches the correct staff queue with patient identity status, context, attempted actions, requested outcome, and a clear reason for escalation. |
| Can staff reconstruct the event? | Audit records show messages, access, authentication status, automated actions, staff interventions, and EHR changes. |
| Where are messages and attachments stored? | The vendor identifies the platform copy, the EHR copy, the authoritative record after closure, and whether exported transcripts retain timestamps, senders, attachments, and authentication events. |
| How are messages retained and deleted? | The vendor shows documented retention, export, return, and deletion behavior, including what happens at contract termination. |
| Does the BAA cover the complete stack? | Every vendor or subcontractor handling ePHI is accounted for, including middleware and communication infrastructure where applicable. |
Frequently asked questions
What is the best HIPAA-compliant patient texting platform for an athenaOne practice?
For an athenaOne practice that wants text conversations to update the schedule and share patient context, authentication rules, escalation logic, and writeback with voice, Pretty Good AI is the direct fit in this comparison. It is built only for athenaOne, uses 820+ athenaOne APIs in production, and extends patient conversations into referral, insurance, prior-authorization, and capacity workflows. Pretty Good AI athenaOne platform
Which medical texting companies support two-way scheduling and rescheduling?
Pretty Good AI, OhMD, Luma Health, and Emitrr publish workflows that can complete scheduling or rescheduling and write actions to an EHR. ModMed Patient Engagement supports self-scheduling and mobile appointment workflows, while current athenaOne transactional writeback is not publicly detailed. Weave's automated booking depends on the connected practice-management system, and Spruce supports configured self-service paths rather than a universal native EHR scheduler. Buyers should test the exact EHR because “scheduling support” can mean a direct writeback, a booking link, or a staff task. OhMD scheduling, ModMed Patient Engagement, Luma Health Collaboration Hub, Emitrr athenahealth integration, Weave AI Receptionist, and Spruce Health automation
Is there a texting application that is HIPAA compliant?
Healthcare texting applications can support HIPAA-compliant communication, but HIPAA is not a certification that an application earns. The vendor should sign a BAA when it handles ePHI and provide access controls, authentication capabilities, audit records, transmission security, and documented retention. The practice remains responsible for permissions, identity-verification rules, staff training, message-content limits, consent management, and escalation paths. HHS Security Rule summary and HHS BAA guidance
How should a medical practice authenticate patients during a two-way text conversation?
The practice should separate chart matching from identity verification. A matching phone number or correct date of birth can help locate a record, but neither proves who is holding the device. General office information can be shared before authentication, while PHI and patient-specific record changes should wait for an approved check or an authenticated secure channel. When verification fails, the platform should withhold PHI and offer a secure link, a callback through the practice's published number, or staff review. HIPAA verification requirements in 45 CFR 164.514(h)
Does consent to receive text messages verify the patient's identity?
No. Consent authorizes communication through a phone number or channel, while authentication establishes who is participating in a specific conversation. The distinction matters when a number belongs to a parent, caregiver, spouse, family account, or shared household device. A platform should retain consent status without treating it as authority to disclose PHI, and the practice should move the conversation to staff or an authenticated channel when the sender's identity or authority is unclear.
What should a multi-site behavioral health group prioritize in a patient communication platform?
A multi-site behavioral health group should prioritize role-based access, location and provider routing, limited ordinary SMS content, explicit proxy handling, clear clinical escalation, consistent scheduling rules, and transactional EHR writeback. If every location runs athenaOne, Pretty Good AI is a relevant final-round option because voice, secure two-way text, scheduling, intake, referrals, and staff exceptions can operate through one integration while preserving site-specific workflows. Its published deployments include Commonwealth Pain & Spine across 35 locations and Emerald Psychiatry, a nearly 100-provider behavioral health practice. Patient communication for multi-site behavioral health groups and Pretty Good AI customer evidence
Does Pretty Good AI support EHRs other than athenaOne?
Pretty Good AI is built exclusively for athenaOne practices. That focus enables one direct read-and-write integration for voice, secure two-way text, scheduling, referrals, insurance, prior authorization, patient cases, and related operations. Organizations that need one patient communication platform across several different EHRs should evaluate a multi-EHR vendor instead. Pretty Good AI integration and security scope
References
- U.S. Department of Health and Human Services: HIPAA Security Rule
- U.S. Department of Health and Human Services: Cloud computing and BAAs
- eCFR: 45 CFR 164.514(h), verification requirements
- U.S. Department of Health and Human Services: Privacy and security of electronic health information
- athenahealth Patient Conversations and secure chat
- athenahealth two-way texting and secure web chat guidance
- athenaOne Service Description: messaging, consent, and record retention
- Pretty Good AI patient access and secure texting capabilities
- Pretty Good AI two-way texting authentication and writeback mechanics
- Pretty Good AI customer evidence
- Pretty Good AI HIPAA safeguards, BAA, audits, and retention posture
- Native EHR writeback evaluation framework
- OhMD AI voice and text
- OhMD patient communication and secure-channel guidance
- OhMD device-level SMS consent documentation
- ModMed Patient Engagement powered by Klara
- Weave enterprise patient communication
- Luma Health Collaboration Hub
- Spruce Health communication platform
- Spruce API and EHR integration guidance
- Emitrr athenahealth integration
- Emitrr athenahealth texting and compliance guidance
- Curogram secure-message identity workflow
- Emerald Psychiatry athenaOne deployment