Healthcare AI regulation is no longer one federal question with one clean answer. A telehealth company may need to review the same feature under FDA software policy, state disclosure rules, HIPAA obligations, professional-practice requirements, and its own clinical governance.
This update is current through August 9, 2026. It covers four developments that should already be reflected in product review and launch operations:
- FDA issued final Clinical Decision Support Software guidance on January 29, 2026.
- FDA published a detailed CDS FAQ on June 29, 2026.
- California’s generative-AI communication rule has been effective since January 1, 2025.
- Texas HB 149 took effect January 1, 2026 and includes a healthcare disclosure provision.
This is an operating brief, not legal advice or a product-classification opinion. Counsel and clinical leadership should confirm which rules apply to a specific care model and software function.
August 2026 regulatory snapshot
FDA final Clinical Decision Support Software guidance
Published January 29, 2026. Read the FDA guidance.
Operator impact: Product teams need to assess each CDS function and intended use instead of relying on a broad label such as “administrative AI” or “provider support.”
FDA Clinical Decision Support Software FAQ
Published June 29, 2026. Read the FDA FAQ.
Operator impact: FDA added practical examples involving surveys, routine calculations, time-critical use, multi-function software, and platform providers.
California Health and Safety Code Section 1339.75
Effective January 1, 2025. Read the California code section.
Operator impact: Covered settings using generative AI for patient communications about clinical information must handle disclaimers and human-contact instructions unless the licensed-provider review exception applies.
Texas HB 149
Effective January 1, 2026. Read the enrolled Texas bill.
Operator impact: A provider using AI in relation to a healthcare service or treatment must provide the law’s disclosure by the date the service or treatment is first provided, with an emergency exception.
The dates matter because these are not proposals waiting on a future product roadmap. They are current sources for 2026 implementation review.
FDA’s June FAQ makes function-by-function review harder to skip
FDA’s January guidance explains the agency’s approach to clinical decision support software intended for healthcare professionals. The June FAQ is useful because it tests that policy against product shapes that show up in vendor demos.
One example covers digitized surveys. FDA says software that only distributes, completes, and shares a well-understood survey is not a medical device. Software that automates simple tasks or calculations may fall outside active enforcement even when it meets the device definition. That does not give every intake algorithm the same treatment. A product that interprets answers, predicts risk, recommends treatment, or changes what happens next has a different intended function.
The FAQ also addresses time-critical settings. Software meant to support time-critical decisions generally cannot qualify as Non-Device CDS because a clinician may not have enough time to understand the basis for the recommendation. But software used inside an emergency department is not automatically a device solely because of the setting. FDA gives the example of software that retrieves recent labs or medication history when a clinician places an order. The function still controls the analysis.
Another useful correction appears in FDA’s answer about the four Non-Device CDS criteria. Failing one criterion does not automatically make a function a regulated medical device. Other FDA policies may place that function outside the device definition or under enforcement discretion. Buyers still need to examine the intended use, output, user, timing, and reliance expected from the clinician.
Multi-function products need the same discipline. FDA says one product can contain Non-Device CDS functions alongside device functions that receive regulatory oversight. A vendor cannot settle that analysis with one product-wide statement.
For telehealth diligence, ask the vendor to separate the functions on screen:
- Which function only stores, retrieves, or formats information?
- Which function analyzes patient-specific data?
- Does any output recommend a diagnosis, treatment, risk score, or next action?
- Can the clinician independently review the basis for that output?
- Is the clinician expected to act under time pressure?
- Does the output remain a draft, or can it change patient status or routing?
The answer should identify the actual workflow and supporting documentation. A slide titled “human in the loop” is not enough.
Platform status does not answer the FDA question by itself
FDA’s FAQ says providers of general-purpose infrastructure, hosting, and development tools are not device manufacturers merely because customers build or distribute medical software on their platforms. The answer changes when a developer provides access to software functions that are medical devices. FDA says a developer offering medical-device software through a website subscription, software-as-a-service model, or similar method may be a device manufacturer.
This distinction matters to a telehealth company buying a platform with optional AI modules. The platform, the module, and the customer’s configured use may raise different questions. Product review should document which party develops each function, who controls the intended use, whether the function is enabled in production, and what claims appear in patient or provider workflows.
Do not ask only, “Is your platform FDA regulated?” Ask for the function inventory and the reasoning behind each function’s status.
California requires the disclosure to appear in the communication
California Health and Safety Code Section 1339.75 applies to a health facility, clinic, physician’s office, or group-practice office that uses generative AI to create written or verbal patient communications about patient clinical information.
For covered communications, the law requires a disclaimer that identifies generative AI involvement and clear instructions for contacting a human. Placement depends on the format:
- physical and digital messages place the disclaimer prominently at the beginning;
- continuous online interactions, including chat-based telehealth, display it throughout the interaction;
- audio provides it at the beginning and end;
- video displays it throughout.
The statute includes an exception when a human licensed or certified healthcare provider reads and reviews the AI-generated communication. That exception should not be reduced to a generic approval toggle. The workflow needs to show who reviewed the communication, when review happened, and which version reached the patient.
California’s rule is also narrower than “all AI needs a disclaimer.” It addresses specified settings and patient communications concerning clinical information. Administrative messages are not automatically the same use case. Counsel should map the statute to each communication lane instead of pasting one disclosure into every screen.
Texas puts disclosure timing into the service workflow
Texas HB 149, the Texas Responsible Artificial Intelligence Governance Act, took effect January 1, 2026. Its disclosure section says that when an AI system is used in relation to a healthcare service or treatment, the provider must give the required disclosure to the recipient or the recipient’s personal representative no later than the date the service or treatment is first provided. An emergency exception allows disclosure as soon as reasonably possible.
That timing requirement belongs in the operating flow. A privacy policy link added after a visit will not solve a requirement tied to the first service date.
A multistate telehealth company should record at least four things for each affected workflow:
- the patient’s state and the legal rule selected for that state;
- the AI function involved in the service or communication;
- the disclosure version the patient received;
- the timestamp and event that prove delivery.
California and Texas should not share one hard-coded script without legal review. Their scope, trigger, format, and exceptions differ.
HIPAA obligations still follow the data
Neither state disclosure language nor FDA software policy replaces HIPAA analysis. HHS OCR’s cloud-computing guidance says a cloud service provider that creates, receives, maintains, or transmits electronic protected health information on behalf of a covered entity or business associate is a business associate, even if the provider cannot view encrypted data.
Before an AI vendor handles ePHI, confirm the relationship, agreement, permitted uses, security controls, subprocessors, retention, deletion, and incident process. A disclosure to the patient does not authorize a vendor to receive PHI, and a BAA does not decide whether the product is safe or lawful for a clinical function.
The clean operating model keeps these reviews separate but connected: FDA function analysis, state disclosure logic, HIPAA/vendor review, clinical ownership, and technical evidence.
What telehealth operators should change now
Start with a production inventory, not a policy memo. List every AI-assisted function touching intake, clinical review, documentation, messaging, support, routing, or analytics. Record whether the function reads patient-specific data and whether its output reaches a patient, clinician, or operational user.
Then assign an owner to each output. A clinical recommendation needs licensed clinical review. A patient communication needs a documented review or disclosure path. An operational classification needs a correction path so staff can fix the record without leaving the original label active elsewhere.
Build state-specific disclosure logic into the workflow. The system should select the right notice, show it at the required point, preserve the delivered version, and log the event. If the business relies on a licensed-provider review exception, preserve the reviewer and reviewed version as evidence.
Finally, test the ugly cases. Ask what happens when the patient’s state is missing, a provider edits the AI draft, the patient changes location, an emergency prevents advance disclosure, or an AI module is enabled after launch. These are ordinary implementation failures, not edge-case theater.
Where Remedora fits
Remedora is the operating layer for branded intake, provider review, prescribing and fulfillment coordination, payments, support, integrations, and audit history. It does not replace counsel, classify a third-party AI function for FDA purposes, or make an AI vendor compliant.
Its role is practical: keep patient state, workflow ownership, review events, and operational evidence connected. If a team adds an approved AI service, that service should have a narrow role with documented inputs and outputs. Remedora remains the record that shows what happened before and after the AI step.
For the broader implementation background, read How AI Is Being Used in Healthcare Beyond the Hype. For platform diligence, use the telehealth platform and patient intake software pages.
FAQ
Did FDA regulate all clinical decision support software in 2026?
No. FDA’s January guidance explains when certain CDS functions may fall outside the device definition, while the June FAQ describes functions that may be devices, may receive enforcement discretion, or may sit outside FDA device oversight under other policies. The analysis is function-specific.
Does a provider review remove every California AI disclosure requirement?
California Section 1339.75 includes an exception when a human licensed or certified healthcare provider reads and reviews the AI-generated communication. Whether a specific workflow qualifies depends on the facts and should be reviewed by counsel. The product should preserve evidence of the reviewer and the version reviewed.
When must a Texas healthcare AI disclosure be provided?
Texas HB 149 says the provider must give the disclosure no later than the date the healthcare service or treatment is first provided. In an emergency, it may be provided as soon as reasonably possible.
Is a BAA enough for a healthcare AI vendor?
No. A BAA addresses part of the HIPAA relationship when required. Buyers still need to review the software function, intended use, state-law requirements, security controls, data flow, clinical ownership, correction path, and audit evidence.
Primary sources
- FDA Clinical Decision Support Software guidance, January 2026
- FDA Clinical Decision Support Software FAQ, current June 29, 2026
- California Health and Safety Code Section 1339.75
- Texas HB 149 enrolled text
- HHS OCR guidance on cloud computing and HIPAA
