Module — Features

Jengu Visit Assistant

Visit Assistant module — recording with audited consent, live clinical assists, visit note generation, smart action detection, televisit, MDT meeting capture, inpatient rounds capture, patient-facing summary.

Inpatient Rounds Capture

A nurse walking inpatient rounds dictates observations bed-by-bed. Each observation knows which patient it concerns (from the patient context selected at that bed) and who is speaking (the nurse, derived from their login). The recording produces structured per-patient observations without manual transcription afterwards.

Why this matters

Inpatient rounds are one of the highest-volume clinical documentation activities in a hospital. A nurse on a ward of twenty patients makes observations on every patient several times per shift — vital signs, mobility, pain scores, mental status, fluid balance, medication response. Documenting all of them in a desktop EHR pulls the nurse out of patient contact for tens of minutes per shift; documenting them on a tablet at the bedside helps but still demands typing while observing.

A spoken-dictation workflow, captured by a tablet that knows which bed the nurse is at, fits the actual rhythm of rounds. The nurse walks, observes, speaks the observation, moves to the next bed. The platform handles the structure: which patient, which observation type, what value. The nurse's hands and eyes are with the patient.

The strategic value: nursing time at the bedside increases, documentation completeness improves, and observations are captured at the moment they happened rather than reconstructed at end-of-shift.

What's in the box

  • Patient context per bed. Each bed in the ward has an identifier (FHIR Location resource) the nurse's tablet recognises (NFC tag, QR scan, or bed-list selection). Selecting the bed sets the patient context for all subsequent recording in that location.

  • Speaker is the logged-in nurse. The recording service receives speaker identity from the tablet's login session. Diarisation is not attempted; the nurse is the only identified speaker.

  • Structured vital-sign recognition. A nurse-tuned AI task recognises common vital-sign formats ("BP 124 over 78", "pulse 72") and produces FHIR Observation resources with the right LOINC code, value, and unit per zone.

  • Narrative content remains as a note. Observations that don't map to a structured vital ("patient seems more alert than yesterday") become clinical-note entries on the encounter.

  • Cross-zone vital-sign codes. The structured recognition uses the zone's preferred coding; an Estonian rounds tablet uses the zone-ee codes, a German one the zone-de codes (when delivered).

  • Edge-resilient. Rounds happen at the edge by default; the recording, structuring, and FHIR write all run edge-side. Cloud reconciliation is not on the rounds critical path.

Standards we lean on

  • HL7 FHIR R4 Observation and Location — the standard shapes for vitals and bed identifiers.
  • LOINC — terminology for the structured vital-sign codes.
  • HIPAA 45 CFR 164.312(a)(1) — access control on bedside documentation devices.

What customers and operators experience

  • A nurse on rounds carries a tablet that recognises the bed they are at. The patient context is set when they arrive.
  • The nurse dictates observations: "blood pressure 124 over 78, pulse 72, fluid balance positive 200 ml since morning, pain score 3, no new mobility issues". The recording captures the speech.
  • The platform structures the observation. Recognised vital signs become FHIR Observation resources on the patient's record; narrative content becomes a clinical note linked to the encounter.
  • The nurse moves to the next bed. Patient context switches; the previous patient's observations are finalised; the new patient's recording starts.
  • A doctor doing morning ward review sees the nurse's observations from the night shift on each patient's timeline, time-stamped, attributed to the nurse who took them.
  • A nurse reviewing their work at end-of-shift sees a list of the observations they recorded across the shift.

Limits and trade-offs

  • Patient-context selection must happen. A nurse who dictates without selecting the bed first produces a speaker-unknown-patient recording. The platform surfaces this as an error to be resolved before the observation enters the record.
  • Vital-sign recognition is bounded. Common formats are recognised; unusual phrasings fall back to free-text notes. The platform errs toward not-fabricating-structure rather than confidently mis-structuring.
  • Background ward noise affects quality. Inpatient ward acoustics are not ideal; transcription quality is bounded by the device microphone and the ambient noise level.
  • Multi-nurse rounds need single-tablet ownership. Two nurses on different tablets work fine; two nurses sharing one tablet need each to log in before their dictation.

Related features

  • Visit recording with audited consent — the same recording mechanism applied to a different context.
  • Smart action detection — observations that warrant action (concerning vitals, medication overdue, abnormal pain trend) surface as actions for follow-up.
  • Platform: Secure recording service — the substrate underneath rounds capture.
  • Platform: Hybrid edge–cloud operation — rounds happen at the edge by default.
  • Platform: Organizational structure — rounds are scoped to the inpatient ward (organisation) the nurse works in.

Live Clinical Assists

Real-time during-encounter prompts: lab order suggestions, drug interaction warnings, role labelling, action detection. Anonymised before any LLM call. Sub-second latency so the clinician sees assists in conversation, not after the fact.

Why this matters

A clinician in a consultation is doing several things at once: listening, examining, deciding, documenting. The cognitive load is real, and the moments where AI can usefully assist are the moments where adding cognitive load is least welcome. Assists that arrive seconds late, or surface in a separate window, or interrupt the clinical flow do not help — they irritate.

The window that matters for live assists is roughly the length of a sentence. A drug-interaction warning that surfaces while the clinician is still saying the prescription out loud is a save. The same warning, shown after the visit ends, is a paperwork item.

Live clinical assists are the platform's answer for the in-conversation case. The pipeline is engineered for sub-second latency on the critical path: keyword filter → lightweight model → assist surfaced. The clinician sees the relevant prompt while the conversation is still on the topic; they can act, dismiss, or note for follow-up without pausing the interaction.

What's in the box

  • Pre-filter before LLM call. A keyword catalogue recognises segments that have no plausible clinical trigger (greetings, casual chat) and skips them. Most segments cost nothing.

  • Anonymisation runs first. Patient identifiers, ID numbers, contextual identifiers are removed before any LLM call.

  • Right-sized model per task. Action detection and role labelling run on a fast model for sub-second latency; pattern-matching against clinical guidelines runs asynchronously on a stronger model.

  • Streaming transcript drives assists. The transcript is produced incrementally; assists evaluate against each finalised segment within the segment's lifetime.

  • Per-zone provider routing. Which AI provider runs each assist task is determined by the tenant's compliance zone through the platform's right-sized AI router.

  • Inline prompts, not modals. Assists appear in a side panel of the visit UI; they do not interrupt the recording or the clinician's documentation.

Standards we lean on

  • GDPR Article 22 — automated decision-making constraints; assists are decision support, not autonomous decision.
  • HIPAA 45 CFR 164.514(b) — Safe Harbor / Expert Determination define the de-identification bar input must clear before reaching any AI provider.
  • EU AI Act (Annex III, healthcare risk class) — clinical decision-support classification informs how assists are presented and audited.

What customers and operators experience

  • A clinician mentioning a medication during the visit sees an interaction check inline if the patient's existing prescriptions contraindicate. The prompt surfaces while the clinician is still finishing the sentence.
  • A clinician saying "let's do a CBC and metabolic panel" sees a one-click lab-order action surface, with the test list pre-populated and the order ready to confirm.
  • A clinician treating a pregnant patient sees relevant context-flags surface ("pregnancy: dose-adjusted limits apply" / "this medication is contraindicated in pregnancy") whenever the conversation triggers it.
  • A clinician who finds an assist unhelpful dismisses it with a single click; the assist disappears and is logged as reviewed-and-dismissed.
  • A clinician in zone-ee sees assists informed by Estonian terminology and Estonian-recognised reference data; a clinician in zone-de (when delivered) sees German ones — same product, different zone-aware data.

Limits and trade-offs

  • Assist quality is bounded by the underlying model and the available context. A clinician using terminology the model was not trained on, or referencing patient context the platform does not have, sees fewer or weaker assists.
  • The platform errs on the side of fewer-but-stronger assists. Suggestion fatigue trains clinicians to dismiss even good prompts. The default tuning is conservative.
  • Live assists run during recording only. A clinician who chose not to record the visit gets no live assists.
  • Latency is bounded by the slowest provider in the chain. Network round-trip to the LLM provider is the largest component; zones that route to remote providers see higher latency than zones that route to local models.

Related features

  • Visit recording with audited consent — recording produces the live transcript live assists consume.
  • Smart action detection — distinct concern: smart actions are detected actions surfaced as one-click; live assists include suggestions that don't necessarily map to an action.
  • Platform: Right-sized AI pipeline — Visits's live assists are routed through the platform's per-zone, per-task-kind AI router.
  • Platform: Patient data anonymisation — anonymisation is the boundary that protects the LLM input.

MDT Meeting Capture

Multidisciplinary team meetings — case reviews, tumour boards, complex case discussions — captured with per-participant identity from the recording context. Each participant's contribution is identified at source; the resulting structured meeting note attributes decisions and rationales to the right speaker.

Why this matters

Multidisciplinary team (MDT) meetings carry decisive clinical weight. A tumour board's recommendation about a patient's treatment plan, a complex case discussion's consensus on diagnosis, an MDT review's conclusion about whether to operate — these are the moments specialists agree on a course of action that no single specialist would have decided alone. The patient's record needs to reflect not just the conclusion but who said what and why.

A meeting captured by one participant's notes loses the multi-voice structure: it becomes "the consensus was X" without the supporting discussion. A meeting captured by audio without speaker identity loses attribution: an inspector reviewing the recommendation later cannot tell which specialist contributed which view.

MDT meeting capture solves both. The recording happens with per-participant identity (each participant's microphone or stream is tagged at source); the transcript carries that identity; the generated meeting note attributes contributions to the right specialist by name, role, and discipline.

What's in the box

  • Multi-stream call channel. Each MDT participant joins as a separate stream; the call platform tags each stream's audio with the participant's identity. The platform's secure recording service consumes the multi-stream input.

  • Speaker identity is metadata, never inferred. The recording service treats identity as input from the call context, not as something to deduce. A participant on a shared microphone is "speaker-unknown" unless the meeting context provides identity.

  • Per-case structure. The meeting agenda lists cases as patient-context boundaries. The transcript for each case is associated with that patient's record; the generated note appears on the patient's encounter.

  • Structured meeting note generation. The drafting AI task produces per-case structured notes (recommendation, rationale, dissent, follow-up actions) attributed to speakers. Same drafting infrastructure as visit notes.

  • Decisions surface as smart actions. An MDT recommendation that requires a follow-up — schedule treatment, order further imaging, refer to another specialty — surfaces as a smart action on the patient's encounter, ready for the treating clinician to confirm.

  • Multi-tenant participation. A specialist from another organisation joining an MDT (e.g., external consultant) participates under a guest identity; their contributions are recorded in the host tenant's record per the host's zone policies.

Standards we lean on

  • HL7 FHIR R4 Composition and CarePlan — the standard shapes for the meeting note and resulting follow-up plans.
  • GDPR Article 9 — special-category data; tightened controls apply to MDT recordings.
  • ePrivacy Directive 2002/58/EC — recorded multi-party communications consent regime.
  • eIDAS (EU 910/2014) — cross-border identity for participants from other EU jurisdictions.

What customers and operators experience

  • An MDT coordinator scheduling a meeting invites participants through the platform's scheduling surface. Each participant joins with their own audio stream; identity is tagged at the moment they speak.
  • An MDT participant joins the meeting (in person or remotely via televisit), sees the agenda, and contributes during their case. Each contribution is attributed to them automatically.
  • An MDT chair sees a structured timeline of the meeting in real time: which case is currently being discussed, which participants have spoken, the time pressure on each case.
  • An MDT clinician reviewing the meeting note afterwards sees attributed discussion: "Dr. Smith (Oncology): recommended chemotherapy regimen X based on Y. Dr. Jones (Surgery): supported, conditional on Z. Dr. Patel (Pathology): noted risk of W."
  • A patient whose case was discussed has the MDT recommendation recorded against their encounter.
  • A regulator reviewing a treatment decision sees the MDT discussion that produced it, with each contributing clinician identified.

Limits and trade-offs

  • Identity quality depends on the meeting setup. A meeting with everyone on per-stream microphones produces high-quality attribution; a meeting with a single mixed microphone in a conference room loses attribution for participants in that room.
  • Cross-tenant meeting data is constrained. When a clinician from one tenant joins another tenant's MDT, the recording lives in the host tenant.
  • Meeting note structure varies by specialty. Oncology MDTs structure differently from cardiology MDTs. Per-tenant or per-zone templates can be configured.
  • MDT scheduling integration is partial. Scheduling surface integration exists for tenants using the platform's scheduling; integration with hospital-wide scheduling systems requires the LIS-bridge-equivalent for the scheduling system.

Related features

  • Televisit — MDT meetings often include remote participants via televisit; same substrate.
  • Visit recording with audited consent — the same recording mechanism applied to multi-party context.
  • Visit note generation — the drafting infrastructure used for the meeting note.
  • Platform: Secure recording service — the substrate with per-stream identity support.
  • Platform: Cross-module clinical workflow — MDT decisions flow as smart actions on the patient's encounter.

Patient-Facing Visit Summary

A lay-language take-home note in the patient's language, generated from the clinician's signed visit note. Includes structured follow-up actions: medications to take, appointments to keep, things to watch for, when to call the doctor. Reduces the gap between what the clinician said and what the patient remembers.

Why this matters

Studies of patient comprehension after consultations consistently show a gap. A patient who heard the clinician's instructions in the moment retains a fraction by the time they get home, and that fraction degrades through the days that follow. The clinician's signed note is not the right document for the patient — it uses medical terminology, reflects clinical reasoning, and is structured for the next clinician, not for the patient.

A take-home note designed for the patient closes part of this gap. It uses lay language, focuses on what the patient needs to do and watch for, and is in the patient's language rather than the clinician's clinical language. It does not replace the medical note; it complements it.

The strategic value is downstream care quality. Patients who understand their treatment plan adhere to it better; patients who know when to call the clinician avoid both unnecessary calls and delayed escalation; patients who can re-read the summary days later carry the consultation forward instead of forgetting it.

What's in the box

  • Generated from the signed clinical note. The patient summary is downstream of the clinician's signed note, not from the raw transcript directly. This ensures the summary reflects what the clinician actually decided, not what the AI thought the clinician decided.

  • Lay-language model task. A specific AI task translates clinical content to lay language. The task is routed through the platform's right-sized AI pipeline; zone-specific provider rules apply.

  • Structured action sections. Medications, appointments, things-to-watch-for, when-to-call are FHIR resources (MedicationStatement, Appointment, CarePlan) the summary references. The same data drives the patient portal's reminders.

  • Translation into the patient's language. The platform maintains a list of zone-supported languages for patient-facing content; the patient's preferred language is part of the patient record. Where the language is supported, the summary is generated directly in it; where not, English (or the zone's default) is used with a note.

  • Delivery channel per tenant. SMS link, email, printable PDF, patient-portal entry — the tenant configures which channel(s) the summary delivers through.

Standards we lean on

  • GDPR Article 12 — transparent communication to the data subject in clear and plain language.
  • HIPAA 45 CFR 164.524 — right of access. Patients receive their record in a form they can use.
  • HL7 FHIR R4 Composition, CarePlan, MedicationStatement, Appointment — the standard shapes underlying the summary's action sections.
  • WCAG 2.2 — accessibility for patient-facing content (reading level, contrast, screen-reader compatibility).

What customers and operators experience

  • A clinician finishing the visit sees the patient summary drafted alongside the clinical note. They review both; edits to the clinical note flow into the patient summary.
  • A patient leaving the visit receives the summary on their phone (or printed, depending on tenant configuration). It is in their language, in plain vocabulary, with structured action items.
  • A patient at home reviewing the summary sees clear sections: "What we discussed", "What to do", "What to watch for", "When to call us". Each section is short.
  • A patient with low health literacy sees a summary pitched for general audiences — short sentences, common words, no jargon. Per-tenant settings can configure the reading-level target.
  • A non-native-language patient receives the summary in their preferred language (where the platform's translation supports it). The clinical content is the same; the language is the patient's.
  • A clinician seeing the same patient at follow-up can reference the prior summary to reinforce or revise the plan; the patient has it on their phone.

Limits and trade-offs

  • Translation quality depends on the language model for that language. A patient receiving a summary in a language with weaker LLM coverage receives a less-fluent summary.
  • The summary is not a clinical record. A patient reading their summary should understand their care plan; they should not use it to substitute for medical advice. Per-tenant configuration controls how prominently this disclaimer appears.
  • Lay-language content can over-simplify. A complex clinical situation summarised as a few short sentences may flatten nuance the clinician intended to preserve. The clinician reviews; the platform encourages but does not enforce nuance.
  • Patient delivery depends on contact details. SMS delivery requires a current phone number; email delivery requires a verified email. Patients without these receive printable PDFs.

Related features

  • Visit note generation — the signed clinical note is the input to the patient summary.
  • Smart action detection — detected actions become structured action items in the patient summary.
  • Platform: Patient data anonymisation — the patient summary contains the patient's identifying content (the patient is the audience), but it is delivered only to the patient, not to AI providers downstream.
  • Platform: Right-sized AI pipeline — summary generation is one of Visits's AI tasks.
  • Platform: Compliance zones — language support and patient-content delivery rules vary by zone.

Smart Action Detection

A small, deliberate set of actions that have to be completed during the visit while the patient is present — slot bookings, on-the-spot referral pickups, follow-ups arranged in dialogue. Triggered either when the conversation calls for one, or when the clinician types into the always-available smart-action box. A focused form opens alongside the live recording; the clinician confirms with the patient; the booking is made, the referral is filed, the appointment exists from that moment. Most things a clinician says do not trigger a smart action — they're handled by note generation or routine detection. Smart actions exist for the few that genuinely need the patient's agreement now, not later.

Why this matters

Most clinical intents stated during a visit ("I'll prescribe amoxicillin", "let's get a CBC", "send a referral to cardiology") do not need to be completed in front of the patient. They become draft entries on the note for the clinician to review and confirm afterwards — that's what visit note generation and live clinical assists already deliver, and that's the right shape for them. Inserting a form into the consultation for every such intent would turn the visit into a paperwork session.

A small fraction of actions are different. They need to be decided together with the patient, while the patient is in the room, because the patient has to agree to specifics — a particular MRI slot at a particular date and time, a follow-up visit scheduled after the MRI result is back, a referral picked from a list of specialists with availability the patient can make. These cannot wait for the post-visit review: the patient is what's missing afterwards.

Smart action detection exists for exactly this case. It surfaces a focused, interactive form during the recording so the clinician and patient can agree and complete the action together — without the clinician switching out of the visit context, and without the action becoming a "to do" item that pushes the booking to some later moment. The design constraint is minimal interruption: fewer triggers, better completion, recording continues throughout.

What's in the box

  • Triggers come from a vetted catalogue. Each smart-action type is explicitly marked as smart-action-eligible — at the platform level for the general types (slot bookings, follow-up scheduling, referral pickups), and within module service catalogues (e.g., Lab's standardized service catalogue) for individual items that need patient agreement at the time of order. The lab director marks the few tests whose nature requires the patient's agreement — a slot-based procedure, a scheduled sample, an after-hours service — while routine tests in the same catalogue do not trigger. Whether an item is smart-action-eligible is a catalogue decision, reviewed like any other configuration in the customer's config repo.

  • Two activation paths. Smart actions can be invoked either by conversation (the LLM detects a triggering phrase and surfaces the action button mid-recording) or by typing (the clinician types into the always-available smart-action box on the visit form; the LLM autocompletes with full, context-aware suggestions like "book first free MRI slot for meniscus from 21 July + follow-up 3 weeks later" or "book MRI asap, then follow-up two weeks after"). Either path opens the same focused form.

  • Focused form, scoped to one action. When a trigger fires, a side panel opens with a form pre-filled from the conversation so far (test type, indication, patient preferences, urgency). The clinician's attention narrows to this form for the duration of the action.

  • Parallel editing in the focus, serial elsewhere. While the focused form is open, the clinician can edit by hand and the LLM can update fields as the conversation produces new information ("actually, push it a week later"). Race conditions inside the focused area are handled deliberately — the focus is what permits parallel editing. Outside the focused form, the rest of the visit's transcript and assists continue updating in their normal serial way; parallel LLM + clinician editing is only permitted inside the focused smart-action form.

  • Patient agreement during recording. The patient is in the room while the action completes; the audio of their agreement is captured in the same recording as the rest of the visit. No separate consent path; the consultation is the consent.

  • Chained smart actions. Completing one action can spawn a dependent one. After the MRI slot is set for date X, "let's arrange follow-up after the MRI result" opens a follow-up smart action seeded with date X + 2 weeks. As the conversation refines ("I'm on vacation that week"), the seed shifts. A typed composite suggestion ("book MRI asap + follow-up three weeks later") is the same chain expressed upfront.

  • Confirmation = the action applied. When the clinician confirms, the booking is made, the referral is filed, the appointment is created. From that moment, this is a real clinical action on the record — not a draft, not a pending task awaiting background processing, not a "we'll get back to you". The patient leaves the visit with the slot already on their calendar. The audit trail records confirmation as the moment of application.

Standards we lean on

  • HL7 FHIR R4 Appointment, ServiceRequest, ReferralRequest — the standard shapes confirmed actions immediately become.
  • GDPR Article 22 — automated decision-making. The clinician's confirmation (with the patient present) is the human-in-the-loop required by the article.
  • EU AI Act (Annex III, healthcare risk class) — clinical decision-support classification informs how smart actions are presented and audited.

What customers and operators experience

  • A clinician saying "let me see when the first MRI slot is for your potential meniscus injury" sees a smart-action button appear inline. One click opens a search-and-book form pre-filled with test type, indication, and the patient's context.
  • A clinician typing into the smart-action box "book MRI for meniscus + follow-up three weeks later" sees an LLM-generated autocomplete list of complete action suggestions; picking one opens the same focused form (or, for composite suggestions, the first form in the chain) with parameters already set.
  • A clinician ordering a Lab catalogue item flagged as smart-action-eligible (e.g., a glucose tolerance test that needs a 2–3 hour slot) sees the same focused-form pattern, pre-filled from the catalogue entry. The slot lives in the Lab module's worklist; the booking is applied through cross-module workflow at the moment the clinician confirms with the patient.
  • The clinician and patient deciding together see slot options. The clinician picks one; the patient agrees out loud; the clinician confirms — and the booking exists from that moment.
  • The clinician adding extra information mid-form ("she's also on a blood thinner — flag it on the request") sees the LLM update the form's relevant field while they keep talking. Manual edits and LLM edits coexist inside the focused form.
  • A chained follow-up — "let me arrange follow-up two weeks after the MRI" — opens a second smart action with the follow-up window already calculated from the just-confirmed MRI date.
  • A clinician saying "I'm on vacation that week, push it a week later" sees the chained follow-up's search window shift accordingly without re-typing the original parameters.
  • A patient leaving the visit has the agreed slot bookings and follow-ups on their calendar already. There is no "we'll be in touch" step.

Limits and trade-offs

  • The trigger catalogue stays small. Adding a new smart-action type — or flagging more items in a module catalogue — is a deliberate choice, not a side-effect of better detection. The constraint is the clinician's attention; more triggers mean more interruptions.

  • Confirmation makes the action real. A clinician who confirms a slot they did not actually intend has booked the slot. The platform treats confirmation as the act of agreement, not a draft step. Cancellation is a subsequent clinical action, audited like any other.

  • A smart action that doesn't complete during the visit is abandoned. It does not queue, does not become a reminder. The intent flows to the note as a regular plan item; the patient doesn't get the slot pre-booked.

  • Parallel editing is only inside the focused form. Outside it, the LLM updates serially and the clinician edits at their own pace. The platform deliberately does not extend the parallel-editing pattern to the whole visit UI.

  • Chained dependencies are best-effort. A follow-up scheduled relative to an MRI date depends on the MRI date being confirmed first; if the MRI booking is abandoned, the follow-up's seed becomes meaningless and the follow-up smart action closes.

  • Booking-style smart actions to external systems depend on EHR integration as a precondition. When the booking target is a system outside the platform — hospital EHR slots, external imaging services, third-party scheduling — the customer's system must be integrated first. This is contract-time setup, not runtime opportunism. Three things have to be agreed up-front:

    1. Near-realtime slot-availability feed. The external service publishes slot-status updates to the platform frequently enough that the options the clinician sees in the focused form are accurate at the moment of the visit.
    2. Near-realtime booking writeback as FHIR. When the clinician confirms, the resulting Appointment / ServiceRequest flows back to the customer's EHR within seconds — so the hospital's own systems reflect the booking the platform just applied.
    3. A customer-side conflict-resolution rule. If two systems attempt the same slot, the customer owns the resolution policy (which one wins, how the losing side is notified, how the patient is informed). The platform surfaces the conflict; it does not decide it.

    Without those three agreements, smart-action bookings to that external system are not enabled for the tenant. Bookings whose target is an internal Jengu module — for example, a slot the Lab module already manages on the platform — do not need this setup; they flow through the platform's cross-module workflow feature and are integrated by definition.

Related features

  • Live clinical assists — surfaces routine suggestions and warnings during the visit; not a smart action. Smart actions are the rare cases that need form-based completion during the visit.
  • Visit note generation — routine intents (prescriptions, lab orders) flow into the note's plan, not into smart actions. Confirmed smart actions are linked from the note's plan section as already-applied.
  • Patient-facing visit summary — confirmed smart-action bookings and follow-ups appear in the patient's take-home summary, already arranged.
  • Platform: Cross-module clinical workflow — confirmed smart actions interact with downstream modules (imaging, scheduling, referral) at the moment of confirmation.
  • Platform: Right-sized AI pipeline — both the detection trigger and the in-form LLM updates run through the platform's per-zone AI router.
  • Platform: Regulatory audit trail — every confirmed smart action is an audit event recording who agreed, when, with what parameters.

Televisit

Remote consultations between clinicians and patients (and between clinicians) over a LiveKit-based video and audio channel — using the same recording, transcription, anonymisation, and clinical assist pipeline as in-person visits. The clinical experience is consistent across in-person and remote care.

Why this matters

Televisits are now a routine part of clinical care, not an exception. Outpatient follow-ups, second-opinion consultations, specialist-to-GP discussions about a shared patient, post-discharge check-ins — all happen as often over video as in person. A platform that treats remote consultations as a separate, weaker product than in-person creates two-tier clinical workflows: live assists for the in-person visit but not the remote one, signed note from the in-person but a different note format from the remote.

The opposite — building televisit on a different stack from in-person — multiplies engineering effort and certification burden. Two recording paths, two transcription paths, two anonymisation paths, two audit trails. Each is a separate compliance review.

Televisit reuses the same substrate. The audio capture happens through LiveKit; the audio reaches the same platform recording service; the same anonymisation runs; the same live assists appear; the same signed note structure results. The clinician's experience and the patient's safeguards are identical.

What's in the box

  • LiveKit is the audio/video substrate. The platform's secure recording service delegates capture, mixing, and routing to LiveKit. Visits is one consumer of that substrate.

  • Same recording-service contract. Audio in, anonymised text out — exactly as for in-person visits. The televisit's audio enters the same anonymisation pipeline, produces the same transcript shape, drives the same downstream features.

  • Speaker identity from the call context. LiveKit participants are identified per stream (per-microphone or per-camera). The recording service receives identity as metadata; the transcript carries it through. No diarisation is attempted.

  • Cross-zone televisit support. A televisit between a clinician in zone-ee and a specialist in another zone routes through the participating tenants' compliance zones; the more-restrictive zone's residency and provider rules apply.

  • Recording opt-in per call. Some televisits should not be recorded (e.g., crisis-line equivalents); the clinician can start a televisit without recording, and the platform records that choice in the audit trail.

Standards we lean on

  • ePrivacy Directive 2002/58/EC — confidentiality of electronic communications and consent for recording.
  • GDPR Article 9 — special-category health data over remote channels.
  • eIDAS (EU 910/2014) — cross-border identity assurance for clinician-clinician televisits across EU jurisdictions.
  • HL7 FHIR R4 Encounter (virtual class) — the standard shape for the remote-encounter record.

What customers and operators experience

  • A clinician scheduling a televisit does so through the same scheduling surface used for in-person; the patient receives a join link.
  • A patient joining the televisit clicks a link, sees a consent prompt, joins the call. Consent is captured the same way as in-person.
  • A clinician in the televisit sees the same live assists they would see in person — drug interactions, lab orders detected, role labelling. The recording surface is identical.
  • A clinician at end of the call sees the same draft note format, the same smart actions, the same patient timeline. Closing the call is the same as ending an in-person visit.
  • A patient receiving a follow-up summary receives the same lay-language take-home note as for an in-person visit.
  • A specialist-to-GP discussion about a shared patient uses a televisit format with multi-party identity carrying through to the transcript.

Limits and trade-offs

  • Televisit quality depends on network conditions on both ends. A patient on poor connectivity produces a poor recording produces a weaker transcript. The platform does not improve audio it didn't get cleanly.
  • Platform-mediated, not browser-only. Televisit requires the platform's UI on both ends; integrations with arbitrary third-party video systems are not supported.
  • Multi-party with mixed audio is harder. When a televisit has multiple participants but audio is mixed rather than per-stream (e.g., one phone calling in to a video conference), speaker identity for the mixed participants is unknown.
  • Recording retention applies. Televisit recordings follow the same per-zone retention policies as in-person; raw recordings expire on schedule.

Related features

Visit Note Generation

A structured, FHIR-shaped clinical note is drafted from the recording's transcript. The clinician reviews, edits, and signs; the signed note appears on the patient's unified timeline immediately. The clinician's documentation time falls; documentation quality and consistency rise.

Why this matters

Clinical documentation is one of the largest cognitive and time costs in clinician work. A clinician who has spent twenty minutes in a consultation often spends another fifteen minutes on the note: reconstructing the chief complaint, organising the history, writing the examination, recording the plan. The note is necessary — for clinical continuity, for billing, for medico-legal record — but the time is taken from the next patient.

A platform that drafts a usable note from the recording flips this. The clinician's time shifts from writing the note to reviewing it. Reviewing is faster than writing, more accurate because it engages a different cognitive mode, and produces notes that are structurally consistent because they were drafted from the same template every time.

The principle: the AI drafts; the clinician owns. Every note is reviewed and signed by the clinician; the platform never publishes an AI-drafted note unsigned. The clinician's name, the clinician's sign-off, the clinician's edits are what make it a clinical record.

What's in the box

  • Anonymised transcript is the input. Note drafting runs on the anonymised transcript stream; raw text never reaches the drafting model.

  • Zone-aware drafting. The note's structure, terminology, and language are configured per zone. A zone-ee draft uses Estonian medical terminology; a zone-de draft (when delivered) uses ISiK-aligned structure.

  • FHIR DocumentReference + Composition. The signed note is stored as a FHIR Composition resource, referenced from the encounter, with structured sections that can be queried independently. Free-text and structured content coexist.

  • Smart actions linked into the note. Lab orders placed during the visit, prescriptions written, referrals generated — all linked from the note's plan section.

  • Edits feed the improvement loop. For consenting tenants, anonymised before/after pairs feed drafting-model improvement through the platform's consented data use programme.

  • The clinician owns the signature. The platform never publishes an unreviewed draft. Every signed note carries the clinician's name and sign-off; what was AI-drafted vs clinician-edited is visible in audit.

Standards we lean on

  • HL7 FHIR R4 Composition and DocumentReference — the standard shape for the signed note and its registry entry.
  • GDPR Article 22 — automated decision-making. The clinician's review and signature are the human-in-the-loop required by the article.
  • EU AI Act (Annex III, healthcare risk class) — clinical decision-support classification informs drafting and review UX.
  • HIPAA 45 CFR 164.514(b) — Safe Harbor / Expert Determination for the de-identification bar input must clear.

What customers and operators experience

  • A clinician at the end of the visit sees a draft note organised in the structure they expect (chief complaint, history, examination, assessment, plan). Lab results referenced in the conversation are linked. Smart actions detected during the visit are listed.
  • A clinician reviewing the draft edits inline. Changes are tracked; the audit trail shows what the AI drafted vs what the clinician changed.
  • A clinician signing the note publishes it to the patient's unified timeline. From that moment the note is a regular FHIR DocumentReference; it can be queried, exported, and referenced like any other clinical record.
  • A clinician picking up another clinician's patient sees consistent note structure across notes — even across clinicians — because the drafting structure is the same.
  • A coding team or billing department sees notes with structured sections, recognisable terminology, and consistent quality. Coding inputs improve.
  • A patient asking "what did the doctor write?" receives a signed note in standard FHIR; portable to any other FHIR-aware system.

Limits and trade-offs

  • Drafting quality is bounded by transcript quality. A noisy recording produces a noisy transcript produces a weaker draft. The clinician's review is meaningful, not cosmetic.
  • The clinician must review. The platform never publishes an unreviewed draft. A clinician who blindly signs is using the feature wrong; the platform encourages review through UX but does not enforce a minimum review duration.
  • Drafted facts that the clinician disagrees with are the clinician's responsibility to correct. The signed note is the clinician's record, regardless of how the draft started.
  • Some specialty notes are harder to draft well. Highly structured specialty notes (specific ophthalmology examinations, certain procedure notes) may need specialty-specific drafting templates that lag behind general-practice ones.

Related features

  • Visit recording with audited consent — the recording's transcript is the drafting input.
  • Smart action detection — detected actions are linked into the drafted plan.
  • Patient-facing visit summary — the lay-language patient-facing summary is generated from the signed note.
  • Platform: Right-sized AI pipeline — drafting runs as one of Visits's AI tasks routed through the platform.
  • Platform: Open standards data portability — signed notes are FHIR Composition / DocumentReference resources; portable like everything else.