Patient-facing AI is no longer one useful product category. A tool explaining a leaflet, an app remembering a consultation, an agent booking an appointment and software delivering a clinician-defined treatment instruction may all look conversational. They differ in what they know, what they may do and who is responsible for the next clinical step.
This overview, originally published in November 2025, is updated to 16 October 2026. It retains the earlier landscape of symptom tools, patient notetakers and condition-support services, while organising the newer examples by function rather than brand popularity. The distinction between current products and development projects is central throughout.
The question for clinicians is not simply which AI app a patient uses. It is what that app contributed to the patient's understanding or care, and what remains to be established independently.
Start with five functions, not a league table
The following is an editorial classification. It is not a regulatory scale or a ranking of clinical safety.
| Function | What the patient is seeking | What must not be assumed |
|---|---|---|
| Information and symptom exploration | An explanation or help deciding where to seek care | A generated answer establishes a diagnosis |
| Patient-owned records and companions | A usable memory of encounters and ongoing concerns | A coherent summary is a complete, verified clinical record |
| Delegated administration | Help finding, contacting or arranging a service | A completed transaction resolves the underlying clinical need |
| Clinician-backed care support | Help within an identifiable care pathway | The chat interface alone supplies the whole clinical service |
| Bounded clinical software or investigational agents | A defined treatment-related function | One authorisation or research award covers every advertised capability |
A product can span several rows. Each additional function creates its own information, permission and evaluation questions. An app should not acquire a broader implied role simply because its interface becomes more capable.
Information assistants and symptom exploration
The earlier landscape included Ada, Buoy and Healthily. Their current product descriptions still illustrate different forms of symptom assessment and navigation: Ada explains a question-based assessment producing possible causes, Buoy offers symptom discussion and care navigation, and Healthily presents Dot as a health-navigation product. These descriptions do not establish identical technology, availability or clinical performance.
AskPatient adds a specific UK-relevant example: conversational access to Patient.info's reviewed information, with stated limits excluding diagnosis, personalised treatment and emergency care. Its role should not be expanded merely because users ask personal questions.
For the clinician, source quality and generated-answer quality remain separate. A respected library can contain the right information while an individual response omits a qualification or the patient misunderstands its meaning.
When reviewing an AI-generated concern, establish the original question, the relevant response and what the patient did because of it. That is more informative than accepting or dismissing the answer according to the platform's name. The dedicated AskPatient explainer examines this consultation workflow in more detail.
Patient-owned records, notetakers and connected companions
Aide Health's Mirror describes recording face-to-face consultations to produce summaries that patients can revisit and share. That is a different function from a symptom assessment, even though both can influence what a patient later believes about their care.
Advoca's September 2026 updates add symptom tracking and connected health data to its broader companion proposition, according to its App Store release history. The main Advoca guide distinguishes those additions from its existing recording, preparation and information features.
The useful clinical opportunity is a clearer patient account: what happened, when, what was discussed and what remains unresolved. The risk is that an interpretation becomes part of the stored history and is reused as fact in later conversations.
A clinician should distinguish the patient's report, a device measurement, a clinician's instruction and an AI inference. The wearable-timeline article provides a practical review checklist. The updated patient-summary provenance article examines what happens when an error becomes the context for another answer.
Research discovery is another distinct function. A patient arriving with a cited paper needs help evaluating its applicability, not simply a verdict on whether AI is trustworthy. The Advoca research-review guide offers a consultation approach based on the clinical question and the evidence.
Delegated administration can change access without diagnosing
A patient-side agent can attempt practical work on the person's behalf. Ferry's launch description illustrates provider search, office contact and appointment arrangements. It operates from the patient's side, unlike a receptionist purchased by a clinic.
The receiving practice needs to establish identity, the scope of the patient's delegation and the information required for the specific transaction. It should not assume that a sophisticated caller has already assessed the clinical significance of the request.
A hypothetical patient may ask for a sooner appointment because their circumstances have changed. Successfully booking a slot does not establish that the timing is appropriate. Equally, an assistant that identifies a missing referral requirement and hands back accurately may have helped even without completing the booking.
Benefits-linked navigation adds another constraint. Ask Revive sits within a US member-care offering. "Available through this arrangement" should remain distinguishable from "clinically preferred for this patient". The Ferry and Ask Revive articles examine those different relationships.
Clinician-backed care is a service, not just an assistant
Some products place the conversation within an identifiable clinical pathway. Dimer's AiME announcement describes post-discharge support connected to a clinical team. MayaMD's current site likewise presents a combination of protocols, patient communication, connected devices and staff supporting clinicians across care transitions and home care.
Other established names need their current positioning considered rather than an unchanged 2025 description. K Health now presents AI-enabled care for health systems, while Aide's flagship product addresses chronic-condition support separately from Mirror's notetaking role. Flok Health is a condition-focused physiotherapy service, not a general-purpose health chatbot.
These examples are not evidence that the services have equivalent staffing, clinical scope or outcomes. The important comparison concerns the whole pathway: what the software does, what the care team does and how a patient reaches the appropriate response when the conversation cannot resolve the question.
An AI escalation is incomplete until its receiving process is understood. The AiME analysis explains why the clinical team, reconciliation process and response arrangements belong in the evaluation.
Narrowly cleared software and investigational clinical agents
Some patient-facing software has a defined treatment-related indication. The UpDoc FDA record, for example, concerns clinician-directed insulin management in adult type 2 diabetes. That specific scope should not become a general assertion that an AI doctor has been authorised for every condition.
Separately, ARPA-H's ADVOCATE programme supports development of cardiovascular agents and supervisory systems. An award or planned evaluation does not establish that the proposed product is already available for routine autonomous care.
The UpDoc, Atman, Tempus Olivia and ADVOCATE supervision articles examine different parts of this distinction. They should be read as product-scope and evaluation discussions, not a comparative clinical-effectiveness ranking.
Research prototypes form another category again. The new EEG and conversational-AI study illustrates why a small inpatient evaluation and a simulated technical improvement should remain separate from claims about long-term home care.
NHS-facing tools and public plans need their own chronology
The Welsh Ambulance service announced the NHS 111 Wales website's multilingual virtual assistant in July 2025. Its described role is helping people find information from the website. That should not be conflated with every part of the wider NHS 111 clinical service.
England's 10 Year Health Plan executive summary sets out several planned NHS App functions. It distinguishes non-urgent navigation through My NHS GP from additional support through My Companion. These are policy descriptions, not proof that all planned functions are already operational in every setting.
An NHS association is relevant context, but not a universal guarantee of answer correctness. Nor are England and Wales interchangeable deployments. Clinicians should identify the exact service, current function and local route before signposting.
Consent is more than deciding to use an app
A patient may agree to store information without understanding every secondary use. Core service delivery, analytics, optional research and disclosure to an external opportunity can involve different choices.
The Advoca consent analysis examines a current example, including the distinction between optional research and separately described analytics. It also explains why a policy review cannot establish that implementation matches every written commitment.
For clinicians, signposting should make the relevant role understandable without offering guarantees about a supplier's complete data practices. Patients should be able to consider alternatives and know where to find current information about use, withdrawal and correction.
What a useful consultation review looks like
Start with the patient's main concern, not the application's feature list. Identify the statement or action that influenced the patient, inspect the relevant source when necessary and distinguish information from interpretation and execution.
A hypothetical patient may bring a timeline, a research paper and a booked appointment from three different tools. Those outputs should not be treated as three independent confirmations of one diagnosis. They may all derive from the same initial assumption.
The agreed plan should state what has been assessed, what remains uncertain and who owns the next step. Where an app-generated account is wrong, correcting that account may be useful, but it does not replace correcting the clinical record through the appropriate process.
The Hello Patient follow-up article adds the provider-side perspective: an operational agent must preserve the conditions in the clinician's plan rather than turn every instruction into unconditional outreach.
Where iatroX fits
iatroX's reference and learning tools support a separate professional workflow. Source-linked answers can help clinicians investigate a general question; Tutor and structured learning can help them examine and retain the underlying reasoning. They do not certify another app's output or replace a patient-specific assessment.
The practical conclusion is to compare patient-facing AI by its job, information, authority and evidence. Some tools explain, some remember, some arrange and some operate within a defined clinical service. The more clearly those roles remain visible, the more useful the technology can be without asking patients or clinicians to trust a category label.
Frequently asked questions
Are all patient-facing AI tools symptom checkers?
No. The category includes information assistants, patient-owned records, administrative delegates, clinician-backed services and narrowly defined clinical software. Their roles and evidence should be assessed separately.
Does NHS-linked content or an FDA clearance make every feature safe?
No. Source quality, product authorisation and the suitability of a particular output are different questions. The exact function, jurisdiction and intended use matter.
How should clinicians respond when a patient brings an AI-generated plan?
Establish the patient's original question and understanding, inspect consequential claims where needed, and distinguish reported facts, software interpretation and actions that actually occurred before agreeing the clinical next step.
Explore source-linked clinical reference for the question in front of you