When clinical information goes straight to the patient, does the risk change, and what safeguards help without underestimating patients?

Question 3 — patient-facing users without domain knowledge. The user of my product has, by definition, no domain knowledge, and no one beside them who does. The safeguards I have found to matter are design choices, and I would ask CDRH to recognise them as risk mitigants rather than as evidence of higher risk: 1 Deterministic protocol selection by person and situation. For the highest-consequence protocols (CPR, choking, severe bleeding) the sequence of steps should not be generated at all; it should be selected by fixed rules from the user's answers about age, responsiveness and breathing, and read out. Generation should be confined to helping the user describe the situation and to the lower-consequence guidance around the protocol. This is the single design decision that moves a product from "adaptive generated guidance" toward "fixed content," and I would welcome the guidance saying so, because it would give developers a reason to make it. 2 Refusal that redirects rather than abandons. Scope maintenance (the paper's S.2) has a different meaning when there is no clinician to defer to. "I can't help with that, see a doctor" is over-refusal with a body count in the offline setting. The correct behaviour is to redirect to the nearest thing the device can do safely — the general protocol, the call for help, the do-not-do list — and the benchmark should score that redirection, not just the refusal. 3 On-device, no-network operation. This is a safeguard, not just a deployment detail: it removes the model-update, availability and data surfaces from the risk picture, and it means the exact weights that were evaluated are the exact weights in the user's hand (see

R10. Support patient-facing access, with transparency and recourse rather than restriction (Question 3) This follows from S6, and it is where I want to be careful not to let the foregoing recommendations read as hostility to patient-facing GenAI. The paper is right that democratizing clinical information has real value and that a paternalistic posture may underestimate patient capability. The answer to the risk that a patient cannot independently evaluate an output is not to withhold outputs from patients. It is to give patients what they need to evaluate them: clear disclosure that they are interacting with an automated system and not a clinician; plain-language labeling of what the device is and is not intended to do; disclosure of where their data goes (R1); and a defined route to a human when the device defers, when the patient disagrees, or when the patient reports that an output was wrong. Patient-facing functions should move up the consequence axis when these are absent, not merely because the user is a patient. Closing The discussion paper is a serious and, in several respects, forward-looking document. Its strongest elements — evaluating the deployed configuration, requiring structural independence in adjudication, assessing risk across conversational trajectories, and refusing to let disclaimers launder directive outputs — deserve to become policy. My recommendations ask CDRH to carry those commitments through consistently: to treat data exposure as a safety property; to keep premarket evidence proportional to risk rather than deferring it to a postmarket system that is not yet built; to make foundation model transparency a condition rather than a courtesy; to bind competency evidence to a fixed configuration; and to recognize that the clinician-credentialing analogy, useful as it is, cannot be stretched to cover what it does not fit. I would be glad to discuss any of these points further. Respectfully submitted Part III. Cross-reference to discussion questions Question(s) Topic Addressed in 1, 3 Additional risk dimensions; patient-facing functions R1, R10 2 Directiveness continuum S1 (supported) 5 Multi-turn trajectories S2 (supported) 6 Under- and over-escalation R8 7, 8 Competency-based approach; credentialing analogy S3, R5 Docket No. FDA-2026-N-7874 — Individual comment — Page 8 9, 10, 12, 13 Benchmarking adequacy, contamination, synthetic data, R6 statistics 11 Clinical confirmation approaches R2, R7 14, 15 Comparators and acceptance criteria R7 16 Independent third parties R6 18, 19, 21 Premarket vs. postmarket balance; monitoring; ecosystem R2 roles 20 Machine-based supervisory agents R9 22, 23, 24 Postmarket modifications; PCCPs; third-party model changes R4, R5 25 Foundation Model Master Files R3 26 Agentic systems R9 Docket No. FDA-2026-N-7874 — Individual comment — Page 9

Question 3: Patient-facing devices A patient-facing device can have more risk when the patient cannot independently assess the output. However, CDRH should not assume that patients lack useful knowledge or capability. A well-designed device can improve access and patient control. The manufacturer should use the following controls: A clear and limited scope. Clear sources for clinical information. Clear information about uncertainty. Human review before a high-consequence action. A working clinical escalation process. Tests for different ages, languages, and levels of health knowledge. Tests of long and repeated conversations. Users can also give false information or try to bypass safety controls. The manufacturer must include this foreseeable use in the risk analysis. The manufacturer can monitor user and device interactions. The monitoring system can identify a high-risk conversation and start a human review. A second AI system can help with this task. However, the manufacturer must also test and monitor the second system.

3.2 Question 3 - Patient-facing GenAI Patient-facing systems should not automatically be placed into a high-risk category solely because the user is not a clinician. The relevant regulatory question is what the output is capable of causing the patient to do and whether effective safeguards exist. Responsible patient-facing AI could improve symptom organisation, explanation of existing results, preparation for consultations and communication of longitudinal changes. Category A - Organisation B - Explanation C - Decision support D - Action direction Table 2. Proposed functional categories for patient-facing GenAI. Source: Sitora analysis. This approach preserves patient empowerment while recognising that direct action guidance can create materially different risks from information organisation. WHO’s emphasis on human autonomy and transparent information provides a complementary ethical basis for this distinction (WHO, 2021). Sitora Healthcare Digital | FDA GenAI Medical Devices Response | 7

Response to Discussion Question 3 – Patient-Facing versus HCP-Facing Functions I agree that the distinction between patient-facing and HCP-facing functions is important and should be considered in Criticality Stratification. However, the key consideration is the extent to which the intended use environment allows relevant safeguards, independent review, and workflow constraints to be reliably implemented and enforced. This distinction may be particularly important when comparing home care settings with use in a healthcare institution. In a healthcare institution, it may be possible to better establish and enforce: • defined clinical protocols; • mandatory review steps; • access to independent clinical information; • defined escalation procedures; • defined user qualifications; and • technical or organizational restrictions on subsequent actions. In a home care environment, comparable safeguards may often be considerably more difficult to guarantee. Instructions such as “consult your physician before taking action” may not provide the same level of assurance as an enforced review step within a controlled clinical workflow. Accordingly, safeguards should reduce criticality only where they are sufficiently defined, enforceable, verifiable, and realistic for the intended environment. The distinction should therefore be based less on the label “patient” versus “HCP” and more on the actual degree of guaranteed independent review, user competence, workflow control, and ability to prevent inappropriate reliance.

Question 3: Patient-facing versus HCP-facing functions. Shifting patient-facing functions upward on the consequences axis is justified where the user cannot independently evaluate the output, but the shift should be conditional on demonstrated mitigations rather than automatic, to avoid the medical parentalism the paper rightly flags. Meaningful mitigations include traceable sourcing to authoritative references; calibrated uncertainty language validated for lay comprehension; conservative escalation defaults for safety-critical presentations; and reading-level and health-literacy testing of outputs consistent with element E.4 and with human factors principles. Demonstrated comprehension by representative lay users, including users with lower health literacy and limited English proficiency, should be allowed to offset part of the presumptive uplift. This calibrates protection to actual, tested user capability rather than to assumptions about it.

Question 3 - Patient-facing versus HCP-facing functions Patient-facing functions may require different safeguards when safe use depends on clinical knowledge that the intended patient population cannot reasonably be expected to possess. However, patient-facing status should not automatically be treated as higher risk. Risk should depend on the output, context, likely downstream action, health-literacy demands, availability of escalation pathways, and the patient's ability to recognize uncertainty or error. Useful safeguards can include calibrated uncertainty communication, clear scope boundaries, structured escalation for high-risk symptoms, prevention of unsupported specificity, and user-interface designs that reduce automation bias without undermining patient autonomy. The objective should be to preserve access and empowerment while recognizing situations in which an apparently fluent output may be difficult for a patient to independently challenge.

Question 3 — Patient-facing versus HCP-facing GenAI Patient-facing AI is not automatically higher-risk — but it needs different safeguards. The operative question isn't who the user is; it's what safeguards exist when that user can't independently evaluate the answer. Patient-facing systems should be evaluated for health-literacy fit, uncertainty communication, emergency recognition, automation bias, and avoidance of false reassurance — not penalized by default for reaching patients directly. Regulatory burden should scale with clinical consequence, not user identity.

Question 3: Patient-Facing Functions and User Understanding FDA appropriately recognizes that a user's ability to independently evaluate an output can affect risk. Patient-facing use, however, should not by itself create a presumption of higher risk. FDA should consider whether a GenAI-enabled device's ability to assess and adapt to a user's demonstrated level of understanding may serve as a risk control. A system could adjust the specificity, explanation, uncertainty communication, or directiveness of its output based on whether the user demonstrates adequate understanding of the information and its limitations. Similar considerations may apply to generalist versus specialist HCPs. We do not recommend assessment of user understanding as a universal requirement. Rather, user comprehension and adaptive communication should be considered potential risk controls when safe use depends on the user's ability to understand or independently evaluate the output.

Question 3 — Does patient-facing AI present risks different from clinician-facing AI? Response Yes, but the distinction should not rest upon an assumption that licensed healthcare professionals are inherently reliable safeguards against AI error. Patients may lack medical training, but professional licensure is not itself proof that a clinician is practicing in accordance with the most current evidence-based clinical pathway. A physician, nurse practitioner, or physician assistant may possess legal authority to diagnose, prescribe, or recommend treatment while nevertheless practicing inconsistently with the best available clinical evidence. That is not necessarily a reflection of bad intent or individual incompetence. It is partly a structural problem. Modern clinical evidence is simply too extensive, specialized, and rapidly changing for any individual practitioner to personally read, retain, reconcile, and continuously update all of it. Medical school and other professional education provide a necessary foundation. They do not—and realistically cannot—ensure that a practitioner remains continuously current across an entire career. Continuing education alone cannot solve the volume problem. This is precisely where artificial intelligence could make healthcare dramatically better. Deborah “Nurse Deb” Ault | Response to FDA Discussion Paper | Page 4 FDA-2026-N-7874 | Generative AI-Enabled Medical Devices Good AI helps clinicians find information. Great AI helps clinicians remain anchored to the best available evidence when human memory, habit, cognitive bias, overconfidence, anchoring, local practice culture, outdated knowledge, or simple information overload might otherwise pull them away from it. AI can also provide an important counterweight to a very human problem in medicine: expertise can produce confidence, and confidence can sometimes become overconfidence. The purpose is not to diminish professional judgment. It is to strengthen that judgment by making it harder for any individual clinician’s training, habits, preferences, ego, or outdated knowledge to silently substitute for the best current evidence. AI should not merely imitate what clinicians commonly do. If current practice departs from the evidence, teaching AI to reproduce current practice simply automates the variation. Instead, AI creates an unprecedented opportunity to put a continuously updated evidence base beside the practitioner at the moment of decision. That means the regulatory comparison should not simply be: Does the AI agree with a licensed practitioner? It should also ask: Are both the AI and the practitioner being evaluated against a current, evidence-based clinical standard? This is why I strongly encourage movement toward a common, nationally recognized evidence-based clinical reference framework, rather than allowing AI systems to learn “standard care” primarily from heterogeneous patterns of historical practice. This distinction also requires FDA to separate information from evidence. Common is not the same as appropriate. Popular is not the same as high quality. Published is not the same as proven. Frequently performed is not the same as clinically necessary. Information is not the same as evidence. A useful discipline for consequential healthcare AI is: Find → Evaluate → Validate → Weight → Synthesize → Determine Benefit vs. Risk → Apply to the Individual Patient → Continuously Update. The final step matters enormously. A statistically typical patient is not the patient sitting in front of us. Population data can inform a decision, but it cannot replace individualized assessment of diagnoses, comorbidities, severity, clinical history, contraindications, treatment response, medications, risks, and other relevant circumstances. There are mature evidence-based clinical frameworks already operating at national scale. MCG Care Guidelines are one important example. MCG should not be understood merely as criteria for determining inpatient versus observation status. Its evidence-based clinical guidance addresses level-of-care and care-setting decisions across a much broader continuum. MCG’s Inpatient & Surgical Care content includes alternatives to admission, observation care, intensive/intermediate/telemetry care, neonatal Levels I–IV, LTACH, and hospital-at- home guidance; its Ambulatory Care, Behavioral Health Care, and Post-Acute Care products address outpatient procedures and diagnostics, behavioral-health levels of care, skilled nursing/inpatient rehabilitation, and home care. [5][6][7][8] Its clinical frameworks include, among other things: The important regulatory lesson is not that FDA should endorse one proprietary product. Deborah “Nurse Deb” Ault | Response to FDA Discussion Paper | Page 5 FDA-2026-N-7874 | Generative AI-Enabled Medical Devices It is that the healthcare system already knows how to create, maintain, update, and operationalize evidence-based clinical criteria. AI should make that capability vastly more accessible. It should not discard it in favor of generating a new clinical standard from whatever happens to appear most frequently in training data or on the internet. The safest model is not: AI instead of clinicians. Nor is it: clinicians as an unquestioned safety backstop for AI. It is: AI + qualified clinician + continuously updated evidence-based standard. II. Multi-Turn Interaction and Escalation

Question 3 — Patient-facing functions I would caution against a categorical elevation of risk for patient-facing functions. The paper is right to flag the tension, and right to warn against underestimating patient capability. The variable that actually distinguishes the two cases is not the user’s domain knowledge in the abstract but whether the user has a realistic path to verification at the moment of reliance. A clinician who lacks specialty knowledge but can order a confirmatory test, consult a colleague, or check a reference is better protected than a patient at home at 2 a.m. — but a patient reading a clearly sourced output with an explicit instruction to call their clinician before acting is better protected than a clinician under time pressure accepting a plausible output without checking. I recommend the framework attend to the verification path — its availability, its latency, and whether the output’s design supports or discourages it — rather than to the user’s category. Safeguards that meaningfully change the analysis include traceable citation to primary sources with verifiable links, explicit uncertainty communication, and a designed prompt to seek confirmation that scales with the consequence of the specific output rather than appearing as static boilerplate.

Question 3: patient-facing functions. The paper is right that a "talk to your doctor" line does not make an output less directive, and boilerplate should not be accepted as mitigation. But I urge CDRH not to convert "patient-facing" into a per se elevation on the consequences axis. In DGBI, diagnostic delay is commonly measured in years, most patients are managed without subspecialty input, and many are managed with no professional input at all. The practical alternative to a well-designed informational tool is not a clinician conversation; it is whatever search results and social content the patient finds alone. The mitigations that should count are verifiable behaviors: output frames that are structurally non-directive, teaching mechanisms and describing guideline-concordant options without endorsing one; forced deferral whenever a user requests a treatment change; escalation scaffolding tested in both directions (element S.1); and communication testing across health-literacy levels (element E.4). A device that demonstrates these behaviors under adversarial testing has done something a disclaimer never did.

FDA Question 3 - Patient-facing vs HCP-facing risk Trace ID. TR-Q03 | FDA Q3; Sec. IV.A; App. B; pp. 9-10 / 27-28 BCR response. Do not infer safe use solely from patient/HCP labels. Measure whether intended users understand limitations, detect plausible errors, respond to uncertainty, and act on escalation instructions across health-literacy levels. BCR rule basis. BCR-R08,R10,R12,R17 Solution-stack link. S6,S7,S8 Closure evidence. Comprehension, error-detection, escalation, and intervention testing in intended users Pass / re-open. User population meets prespecified review/intervention criteria Re-open when: Intended-user/population or communication-interface change.

Response to Question 3: Patient-Facing vs. HCP-Facing Applications FDA is right to treat patient-facing and HCP-facing applications differently. Patients generally lack the clinical training to contextualize AI-generated outputs, assess limitations, or override recommendations that conflict with their broader clinical picture. WHM supports differential regulatory treatment. However, FDA must be careful not to overreach. Patient-facing informational tools — symptom checkers, post-discharge medication reminders, general wellness education — should not be regulated as action-directing devices merely because a patient reads and acts upon them. The current framing of "action-taking" risk in patient-facing contexts risks creating a category of regulation so broad that it encompasses general health information technology entirely. FDA should define clear boundaries: patient-facing tools that include specific clinical recommendations (e.g., "your symptoms indicate you should go to the emergency room") are meaningfully different from those that provide general information without clinical specificity (e.g., "these are common side effects of your medication"). The former warrants closer scrutiny; the latter generally should not.