Skip to main content

Telehealth AI Assistants: Compliant Virtual Care with Gateway Governance

Telehealth assistants are useful precisely where governance gets difficult: intake conversations, visit preparation, after-visit summaries, and patient questions all happen quickly, often through browser or mobile surfaces, and often with raw patient context. Keeptrusts helps by moving enforcement to the gateway so PHI protection, provider restrictions, medical disclaimers, and escalation behavior are applied before any assistant output becomes part of a virtual-care workflow.

Use this page when​

  • You are building telehealth chat, intake, or virtual-care support assistants.
  • You need a route that protects patient data and limits unsafe medical output.
  • You want an operational pattern that works across web, mobile, and internal care-team tools.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Technical Leaders, Security and privacy teams

The problem​

Telehealth compresses the distance between AI output and patient action. That is what makes it attractive and what makes it risky. A seemingly low-stakes virtual-care assistant can end up answering symptom questions, summarizing medication history, drafting clinician replies, and preparing visit context in the same session. Each step raises a different compliance question.

On the input side, the traffic is full of PHI. Patients type names, dates of birth, addresses, medication lists, insurance details, and symptoms without thinking in compliance categories. On the output side, the assistant can drift from administrative help into medical guidance. That is a poor place to rely on prompt wording alone.

Telehealth teams also face an architectural trap. Because virtual-care products are often browser-heavy, teams are tempted to wire model access directly into the frontend or to scatter lightweight API wrappers across different services. That is the opposite of what you want for healthcare governance. The safer design is the one described across Keeptrusts healthcare docs: a governed gateway route with one enforcement chain and one event trail.

The healthcare sources already define the building blocks. Healthcare (HIPAA) describes PHI, audit, and access-control patterns. Healthcare (EU GDPR) covers minimization and cross-border concerns. HIPAA PHI Detector covers text-focused PHI detection and redaction. Healthcare Compliance governs medical-output phrases and disclaimers. Secure Healthcare AI ties those together as a practical operating model.

For telehealth, the important point is that you need all of those at once. PHI protection without output governance is insufficient. Output governance without provider restrictions is insufficient. Provider restrictions without logging are insufficient. Virtual care requires a chain.

The solution​

The right telehealth pattern is to treat the assistant as a governed edge service, not as a model embedded into the app.

Start with data-routing-policy, hipaa-phi-detector, and pii-detector so patient data is either redacted or blocked before it reaches any provider. Add rbac if staff-only routes and patient-support routes are distinct. Then add healthcare-compliance so the route can block configured diagnosis or prescribing phrases and prepend a medical disclaimer when output looks like advice. If a route should stop rather than deliver a risky output, place human-oversight on that path and let the downstream review workflow handle the escalation.

This works especially well for telehealth because it keeps governance consistent across multiple interfaces. The patient web app, care-manager console, and internal agent tools can all use the same route and the same evidence trail. That is much easier to review than several custom model integrations with slightly different guardrails.

Implementation​

This example shows a telehealth assistant route for intake support and after-visit follow-up messaging. It protects PHI, enforces compliant provider selection, and governs the output language.

pack:
  name: telehealth-virtual-care
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: openai-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0

policies:
  chain:
    - prompt-injection
    - rbac
    - data-routing-policy
    - hipaa-phi-detector
    - pii-detector
    - healthcare-compliance
    - audit-logger

policy:
  prompt-injection: {}

  rbac:
    deny_if_missing:
      - X-User-ID
      - X-User-Role

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    on_no_compliant_provider: block
    log_provider_selection: true

  hipaa-phi-detector:
    action: redact
    mode: hipaa_18
    safe_harbor_method: true

  pii-detector:
    action: redact
    healthcare_mode: true

  healthcare-compliance:
    blocked_patterns:
      - prescribe
      - increase the dose
      - surgery is necessary
    required_disclaimers:
      - This is not medical advice. Contact a licensed clinician or emergency services when urgent care is needed.
    fda_class: III

  audit-logger:
    immutable: true
    retention_days: 2555
    hipaa_audit_controls: true

For a telehealth team, the main benefit of this configuration is predictability. The same route protects patient-entered text in intake, patient follow-up messages, and support interactions. You do not need three separate sanitization strategies.

If you have a route that supports internal clinical review rather than patient-facing messaging, add human-oversight with action: escalate so risky outputs stop instead of being delivered automatically. Keep the behavior description implementation-accurate: the current policy is a simple escalation switch, and downstream systems handle assignment or queue ownership.

The rollout check is straightforward:

kt policy lint --file ./telehealth-virtual-care.yaml
kt gateway run --policy-config ./telehealth-virtual-care.yaml --port 41002
kt events tail --policy hipaa-phi-detector
kt events tail --policy healthcare-compliance

That verifies the route loads, PHI-related events are visible, and medical-output controls are active.

Results and impact​

The immediate result is lower compliance variance across digital care surfaces. Telehealth products often evolve quickly, and policy drift usually follows feature growth. One team adds AI follow-up messaging. Another adds visit preparation. Another experiments with patient education chat. If each feature wires the model differently, governance becomes a patchwork.

With a governed route, the platform standard becomes reusable. Product teams can move faster because the sensitive parts of the stack are already decided. Security teams review one enforcement chain instead of several code paths. Privacy teams can sample events and exports from a single system of record. Clinical governance teams know where disclaimers, blocks, and escalations are actually enforced.

That consistency is what makes telehealth AI sustainable. The challenge is not only to protect one assistant. It is to keep ten future assistants from quietly weakening the control boundary.

Key takeaways​

  • Telehealth AI needs both PHI protection and medical-output controls because input and output risks are different.
  • A governed gateway route is safer than embedding raw model access across browser and service surfaces.
  • healthcare-compliance handles disclaimer and block behavior for medical-looking output, while hipaa-phi-detector and pii-detector protect the prompt path.
  • Use human-oversight only where a deterministic review stop is required, and describe it accurately as an escalation switch.
  • Keep the healthcare reference links close at hand: Healthcare (HIPAA), Healthcare (EU GDPR), HIPAA PHI Detector, Healthcare Compliance, and Secure Healthcare AI.

Next steps​