HIPAA statement

Our role

Care Tales, Inc. is not a covered entity. We do not provide treatment, we do not bill health plans and we do not operate a health plan or a clearinghouse. This document is therefore not a Notice of Privacy Practices.

Our customers are healthcare organizations. When a customer is a covered entity, or a business associate of one, and we create, receive, maintain or transmit protected health information on that customer's behalf, Care Tales acts as a business associate under 45 CFR Parts 160 and 164. In that relationship the customer decides what information enters the platform and why. We process it only to deliver the service and only as a signed business associate agreement permits.

The platform is built for HIPAA compliance. Care Tales is not HIPAA certified, because no such certification exists, and we have not been audited against HIPAA by an outside party.

What we treat as protected health information

Earlier Care Tales material described patient education modules as collecting no protected health information. That description is too narrow and we are correcting it. Where a patient is identifiable to the customer or to us, the record set can include:

• which condition specific module a patient opened, how far they got and at what reading level
• quiz answers, including which wrong option was chosen
• pre module and post module survey answers, star ratings and free text rating comments
• verbatim patient messages and verbatim assistant responses in the organization chatbot
• for account holders, profile fields such as name, phone number and chosen health areas, and legacy onboarding fields including date of birth, conditions, medications, gender, education, barriers, motivations, learning styles and confidence
• a phone number and consent record where a module link is sent by SMS

Our database rules already treat the legacy onboarding fields as protected health information and restrict them accordingly.

Patients who arrive by QR code or link without an account are not identified to us by name. We still hold a persistent visitor identifier, a truncated IP address, a full user agent string and the content above. Whether that combination is protected health information in a given deployment depends on the customer's context, so we handle it under the same controls.

Safeguards in place today

Full detail is in the security overview. In summary:

• Firebase Authentication with server minted session cookies that are httpOnly, secure and same site lax, with revocation checked on every API request
• roles re-read from the database on the server, never trusted from a cookie
• two factor authentication with an authenticator app required for every staff and provider role, with a US phone allowed as a backup, and an enrolled account refused if it does not present a code
• default deny database rules, per organization tenancy, patient chat transcripts readable only by Care Tales admin and team or by a provider of that organization and no client path that lets a user grant themselves a role
• storage rules with tenant isolation, owner only profile photos and size and content type limits
• every non public API checks roles, and routes that expose protected health information narrow further to admin and team
• aggregate chatbot insight terms appear only when used in at least three conversations, and raw messages never leave the server
• rate limits on chat, contact, speech and SMS
• HSTS, nosniff and referrer policy headers, with frame denial on the console and the portal
• encryption in transit and at rest as provided by Google Cloud defaults
• per organization model keys are unreadable by any client
• the internal connector issues per area grants and writes an audit log entry for every call
• modules are reviewed by Care Tales staff before they are marked verified
• a per organization switch that turns off AI features entirely

What is not in place today

We would rather you learn this from us than from a questionnaire.

1. No SOC 2 report, no HIPAA certification, no external security audit and no third party penetration test.
2. No Content Security Policy on the web application. Public chat endpoints accept requests from any origin.
3. No per person log of staff reads of patient data through the product. Google Cloud audit logs record every database read, but reads made through the web application are attributed to the application, not to the staff member. Internal connector calls are audited per person.
4. No retention schedule and no automated deletion of patient data. Records persist until the account or the organization is deleted.
5. No self service route for a patient without an account to reach, correct or delete their own data. Those requests must come through the customer.
6. There is no business associate agreement workflow inside the product. Agreements are handled on paper.
7. Deleted data can persist in weekly database backups for up to 98 days. All data is in Google Cloud in the United States: Firestore in the nam5 multi-region, files and services in us-central1, backups in the US multi-region.
8. Rate limiting is applied per server instance rather than globally.
9. Application level field encryption is not implemented. We rely on Google Cloud encryption at rest.
10. The WordPress widget stores a full untruncated IP address along with coarse geolocation and device details.
11. There is no age verification, although our published terms state a minimum age of 13.
12. Staff offboarding is manual and not scripted.

Several of these are on our roadmap. None of them are represented as complete.

What the customer is responsible for

• Executing a business associate agreement with Care Tales before any protected health information is placed in the platform.
• Deciding what goes into the organization knowledge base and the organization system prompt, and keeping protected health information out of module content, which is shared across patients.
• Telling patients how the organization uses Care Tales, including that chatbot conversations are recorded and that responses are generated by an AI model.
• Managing its own workforce: who receives provider access, when access is removed and whether staff enroll in two factor authentication promptly.
• Sending us deletion, access and amendment requests it receives from patients, since we cannot identify an account-less patient on our own.
• Deciding whether to supply its own model key for indexing its documents. Patient messages never use it.
• Its own minimum necessary determination for anything it uploads or sends to us.

Breach notification

Our proposed contractual commitment is to notify the customer of a known breach of unsecured protected health information without unreasonable delay and in no case later than 48 hours after discovery, and to follow that first notice with a full report within ten calendar days. An impermissible use or disclosure, or any other security incident we become aware of, is reported on the same timetable. Routine unsuccessful attempts such as port scans and failed sign-ins are reported only in aggregate and only on request. The same two windows apply to a personal data breach under our data processing addendum, so one incident produces one set of deadlines. The operative wording is in the business associate agreement.

Subprocessors and AI

We use subprocessors to run the service, including Google Cloud, Firebase and Google Gemini models. The current list is in the subprocessors document. How AI is used, what is sent to a model and what is stored is in the AI disclosure.

Contact

Questions, agreements and security questionnaires: support@caretales.com.

Changes to this document

We update this statement when our controls change. Material changes are published here with a new effective date and notified by email to the administrative contact for each customer organization.