How to Add an AI Clinical Scribe to a Telemedicine Platform (Without Breaking HIPAA)

By Stan Reshetnyk, CTO, Trembit — HIPAA/KBV-compliant telemedicine architecture and real-time AI integration · Last updated 15 July 2026

An AI clinical scribe is ambient software that listens to a clinician–patient conversation during a visit and drafts a structured clinical note — a SOAP note, an assessment, a problem list — instead of just a raw transcript. In a telemedicine platform, it taps the live audio of the video call, runs it through speech-to-text and a language model, and hands the clinician a draft to review, edit, and sign. That is very different from a transcription tool (which gives you words, not a note) and from a chatbot (which talks back). The demand is real and growing fast. So is the risk: an ambient scribe is legally a recording device sitting on top of protected health information, and if you wire it into your platform carelessly, you create a HIPAA and patient-consent problem that a lawsuit can find. This guide is the developer’s-eye view nobody publishes — where the PHI actually flows, which hop needs its own BAA, when patients must consent, who has to sign the note, and how to keep hallucinated content out of the medical record.

Key takeaways
– The ambient clinical intelligence market was estimated at ~$7.24B in 2025, projected to ~$56.61B by 2035 (CAGR ~22.85%). Adoption is already at scale: Kaiser Permanente ran an ambient scribe across 7,260 physicians and 2.5M+ encounters in 14 months through Dec 2024.
– An AI scribe is not “HIPAA compliant” on its own. It’s only as compliant as its weakest uncovered hop. Every vendor that touches PHI in the pipeline — STT, LLM, note storage — needs its own signed Business Associate Agreement.
– Patients generally need to consent, and in ~12 US states it’s a legal requirement, not just good practice (two-party/all-party consent states, as of July 2026 — verify current state law). Sharp HealthCare is facing a class action (filed Nov 2025) alleging 100,000+ patients were recorded via an AI scribe without valid consent.
– AI notes are drafts, not records. The clinician must review, edit, and attest before anything becomes part of the chart or supports a bill. This is the single most important control against hallucinated content.
– Hallucination is a documented, non-trivial risk — fabricated exam findings and misattributed statements are the dangerous failure modes, not typos.
– The compliance gaps in an AI scribe hide in the seam between the video transport and the AI layer — most teams that build one or buy the other don’t see the seam until it breaks. Trembit works both sides of it: HIPAA/GDPR-compliant WebRTC video transport and the real-time AI pipeline on top. Our KBV certification (rare among WebRTC teams) is the kind of operational-compliance discipline this build demands.

What is an AI clinical scribe, and how is it different from transcription?

An AI clinical scribe listens ambiently — the clinician doesn’t push a button per sentence; the tool captures the whole conversation in the background — and produces a structured clinical note as output: history of present illness, assessment, plan, coded problems. A transcription tool gives you a verbatim word-for-word transcript and stops there. A chatbot generates conversational replies. The scribe’s job is narrower and harder than any of them: turn messy spoken dialogue into the specific document format a clinician can sign and a payer can accept.

Three distinctions matter when you’re building:

• Ambient vs. push-to-record. Ambient capture is what makes the tool useful (the clinician stays present with the patient) and also what makes it legally a recording device (see the consent section).
• Structured note vs. raw transcript. The LLM step is doing clinical summarization and structuring, not just cleanup. That’s where hallucination enters — a summarizer can invent a finding that was never said.
• Where it sits relative to the EHR. The scribe drafts; the clinician reviews; the signed note is written to the EHR. The scribe is upstream of the record, never a direct author of it.

For the “why adopt this at all” business case — clinician burnout, documentation time, ROI — the clinical and vendor literature already covers that ground thoroughly — and our guide to what actually works in healthcare AI maps where ambient scribes sit among the production-ready use cases. This guide assumes you’ve decided you want the feature and focuses on the part nobody else documents: how to build or integrate it without creating a compliance problem.

How does an AI scribe pipeline actually work inside a video visit?

Non-technical reader? This section and the next two are the engineering detail — if you just want the compliance decisions, skip ahead to the consent question and the integration checklist.

At a mechanical level, an ambient scribe is a three-stage pipeline hanging off your call’s audio: speech-to-text (STT) → language model (LLM) structuring → structured-note output. Each stage is a place where PHI lives, and each is a decision with compliance consequences.

The STT → LLM → structured-note pipeline, step by step

1. Audio capture. You get a stream of the visit audio — ideally both sides of the conversation, diarized (labeled by speaker) so the note can attribute statements correctly. Treat diarization accuracy as a known weak point, not a solved step: mislabeled speakers are a direct source of the misattribution errors covered in the accuracy section below.
2. Speech-to-text. An STT engine transcribes the audio to text, usually with speaker labels and timestamps. This is the first vendor that handles raw PHI-bearing audio.
3. LLM structuring. A language model takes the transcript and produces the clinical note in the required format. This is the second PHI-handling vendor, and the step where fabrication risk concentrates.
4. Structured-note output. The draft note is stored, surfaced to the clinician for review, and — only after sign-off — written to the EHR.

The naive version of this is a few API calls. The compliant version is a governed data flow where you can name, for every byte of PHI, which vendor holds it, under which BAA, encrypted how, retained how long. The gap between those two is the entire subject of this article.

Where it taps into the WebRTC audio track: client-side capture vs. server-side extraction

In a WebRTC telemedicine visit, there are two places to get the audio, and the choice shapes your architecture and your PHI map:

• Client-side capture. You tap the local MediaStream in the browser or app and send audio to your STT vendor from the client (or relay it through your backend). Simplest to reason about, but you’re now managing PHI egress from every patient and clinician device, and mobile network jitter can degrade the audio the scribe hears.
• Server-side / SFU-side extraction. If your calls already route through a Selective Forwarding Unit (SFU) — Janus, mediasoup, LiveKit — you can fork a clean, server-side audio track to the scribe pipeline. One caveat worth stating plainly, because it changes the build estimate: an SFU forwards encrypted media (SRTP) between participants without decrypting or mixing it by default — that’s what makes it an SFU rather than an MCU. Getting a usable server-side track means adding a specific component: an egress/recording service (e.g. LiveKit Egress, mediasoup PlainTransport), or a bot participant that joins the room and decodes the media like any other client. That’s real media-pipeline work, not a property you get for free from “having an SFU.” Done right, it centralizes PHI handling, gives you one place to enforce encryption and logging, and generally yields more consistent audio — but your media server (and that egress component) is now in the PHI path and inside your BAA/compliance boundary.

Which one is right depends on your existing transport. If you’re already deciding your media topology, our guide on choosing an SFU for your telemedicine platform walks through the Janus vs. mediasoup vs. LiveKit trade-offs — the same server-side track you’d fork for recording is the one you’d fork for the scribe. This is exactly the kind of work we do when we integrate AI into the live media path: the scribe is one more consumer of an audio fork you should already be able to produce cleanly.

Real-time (in-visit) vs. post-call (asynchronous) scribing

• Real-time. The note builds during the visit; the clinician can glance at it live. Lower latency budget, harder engineering, more moving parts holding PHI simultaneously.
• Post-call. You record the visit (or buffer the transcript) and generate the note after the encounter ends. Simpler, more forgiving of latency, but it means you’re storing a full recording — which raises the retention, encryption, and consent stakes.

Neither is “more compliant” by default. Post-call scribing sounds safer but often stores more PHI for longer; real-time can process-and-discard audio but has a larger live attack surface. The compliant choice is the one whose data flow you can fully account for.

Where does PHI flow, and which hop needs a BAA?

This is informational and technical guidance, not legal advice. HIPAA, its enforcement, and vendors’ BAA-eligible-service lists change without notice. As of July 2026, the rules below reflect our reading of HHS guidance and vendor terms, but you must confirm current requirements with your own compliance/legal counsel and each vendor before handling real PHI. Do not rely on this article’s date alone.

The core discipline is simple to state and easy to get wrong: map every hop, and make sure every hop that touches PHI is covered by a signed Business Associate Agreement (BAA).

Map every hop

A typical ambient-scribe data flow looks like this:

Browser/app mic  →  WebRTC media transport (SFU / media server)
                 →  Speech-to-text vendor
                 →  LLM vendor (note structuring)
                 →  Note storage (your database)
                 →  EHR write-back

PHI — the patient’s voice, then their transcribed words, then a structured clinical note about them — is present at every stage. That means every party in that chain that is not you is a business associate under HIPAA, and each one needs its own BAA.

The “every hop needs its own BAA” rule

The mistake we see most often: a team has a BAA with their EHR vendor and assumes they’re covered. A BAA with one vendor covers only that vendor. Your EHR’s BAA does not cover your STT vendor. Your STT vendor’s BAA does not cover your LLM vendor. If you send transcribed PHI to a language model whose terms don’t include a signed BAA for that specific use, you have an uncovered hop — and an uncovered hop is a HIPAA problem regardless of how good the rest of your stack is. An AI scribe is only as compliant as its weakest uncovered hop.

Two practical consequences:

• Check the service, not just the vendor. Many AI vendors offer a BAA for some products or API endpoints but not others. “Vendor X will sign a BAA” is not the same as “the specific endpoint I’m calling is in-scope under that BAA.” Confirm the exact service is covered.
• Read what’s inside the BAA, not just whether one exists. A signed BAA is a contractual obligation, not a technical control — it doesn’t stop a vendor from retaining your PHI longer than you expect or training on your data by default. Check the retention terms and the model-training/opt-out language for the specific endpoint. “BAA signed” is where diligence starts, not where it ends.
• De-identification has limits. Stripping obvious identifiers doesn’t reliably de-identify a clinical conversation — voice is biometric, and free-text notes are dense with re-identifying detail. Treat the whole pipeline as PHI-handling unless you’ve met the HIPAA de-identification standard properly; assuming “we removed the name so it’s fine” is how uncovered hops sneak in.

For the broader video-layer compliance picture underneath all of this — encryption in transit and at rest, storage, the full BAA chain for the call itself — see our guide to the general HIPAA-compliant video architecture. This piece is the scribe-specific layer on top of that foundation.

The OpenAI Realtime API audio-modality gap

One specific trap deserves a flag: whether a given AI vendor’s real-time audio endpoint is HIPAA-eligible is not the same question as whether its text API is. A vendor can offer a BAA that covers text while its low-latency audio modality sits outside that coverage — which matters a lot for a scribe that wants to stream live call audio. We deal with the specifics of the OpenAI Realtime API’s audio-modality HIPAA gap in a dedicated piece — the OpenAI Realtime API’s audio-modality HIPAA gap. The one-sentence takeaway: don’t assume “we have a BAA with the vendor” extends to their streaming audio endpoint; confirm the audio modality specifically.

Do patients need to consent to AI scribing — and what does that consent actually require?

Informational, not legal advice. Consent law is state-specific and changes. Confirm current requirements for every state you operate in with your own counsel — do not treat the list below as permanent.

Short answer: yes, as a matter of good practice everywhere, and as a matter of law in roughly 12 US states as of July 2026. An ambient scribe records the conversation, which makes it a recording device — and recording law, not just HIPAA, governs it.

Why an ambient scribe is legally a recording device

HIPAA governs how you handle PHI. It does not, by itself, resolve whether you were allowed to make the recording in the first place. That’s wiretapping/eavesdropping law, and it lives at the state level. Because an ambient scribe continuously captures the conversation, it falls squarely under those recording-consent statutes.

State-by-state consent variance (illustrative, dated — verify current law)

The US splits into one-party-consent and two-party/all-party-consent jurisdictions. In one-party states, one participant’s consent to record is enough. In two-party/all-party states, everyone in the conversation must consent. As of July 2026, roughly 12 states are commonly listed as two-party/all-party: CA, CT, DE, FL, IL, MD, MA, MT, NH, OR, PA, WA.

Treat that list as illustrative and time-stamped, not evergreen. States move between categories, courts reinterpret statutes, and telehealth spans state lines. The safe engineering posture is to design for all-party consent everywhere — capture explicit consent from the patient as a first-class step — so you don’t have to maintain a per-state branching consent matrix that goes stale.

What went wrong at Sharp HealthCare

The cautionary tale is concrete. In November 2025, a class action (Saucedo v. Sharp HealthCare) was filed in San Diego Superior Court alleging that 100,000+ patients were recorded via an AI scribe without valid consent. The complaint alleges that boilerplate consent language was used despite the absence of a reliable consent workflow.

The lesson for builders is precise: consent is a workflow, not a checkbox in your terms of service. Boilerplate language buried in an intake form is what got named in the complaint. A real consent workflow captures the patient’s explicit agreement to AI scribing, at the point of the visit, in a way you can prove later — timestamped, logged, tied to the encounter.

Cross-state telehealth: which state’s consent rule controls?

When the clinician is in one state and the patient in another, which consent rule applies is a genuinely unsettled, fact-specific legal question — and exactly the kind of thing to route to counsel, not to resolve in an architecture doc. The defensible engineering answer is the same as above: apply the strictest applicable standard (all-party, explicit, logged) so you’re covered regardless of which jurisdiction’s rule prevails.

Who has to review and sign off on the AI-generated note before it’s final?

The clinician does — always. The AI produces a draft; a licensed clinician reviews it, edits it, and attests to it before it becomes part of the medical record. There is no compliant path where a scribe’s output flows unreviewed into the chart.

AI notes are drafts, not records

The regulatory framing supports this directly. Under ONC’s HTI-1 Final Rule, predictive AI (which includes ambient scribes) built into certified health IT must meet transparency, risk-management, and fairness criteria — and these tools are designed as clinician-review instruments: the AI drafts, the clinician reviews, edits, and signs. The clinician’s review-and-attest step is not a nicety layered on top; it’s the control that makes the whole arrangement defensible, and it’s your primary defense against hallucinated content reaching a patient’s record.

Operationally, that means your workflow must make review real, not rubber-stamped: surface the draft clearly, make edits easy, capture an explicit attestation action, and log who reviewed what and when. Enforce it in the system, not just the policy — the EHR write should be gated behind an explicit attestation event (a state the note can’t leave until a clinician signs), so an unreviewed draft physically cannot reach the chart if someone’s tab times out or they move to the next patient.

What does CMS say about billing for AI-assisted documentation?

Here the ground is shifting, so tread carefully. As of July 2026, the AMA’s CPT code set recognizes AI-augmented services for the first time, and the consistent theme across payer guidance is that AI may assist but cannot replace the clinician: the physician remains responsible for reviewing and validating any AI-derived content before it supports a bill.

Beyond that, CMS’s position on AI-assisted billing is still forming — we could not confirm a primary CMS source stating a settled “AI notes are billable with attestation” rule, so don’t treat that as decided. What is reasonably clear is the direction: AI-assisted documentation will be held to the same physician-attestation and validation standard as physician-authored notes, with growing expectation that you can show the provenance of AI-assisted content. The safe design is auditable data lineage from audio → transcript → draft → attested note, so you can show a payer exactly what the AI contributed and that a physician validated it.

What ONC’s HTI-1 transparency rule means for your tool

If your scribe lives inside certified health IT, HTI-1’s transparency requirements apply: you must be able to describe the AI’s intended use, its inputs, and its limitations, and manage its risk. For the broader governance framework this fits into — clinical-AI risk management beyond the scribe use case — see our clinical-AI compliance frameworks guide — DCB0129/0160, HIPAA, and the governance layer. This piece deliberately stays scribe-specific; that one covers the general governance layer.

How accurate are AI clinical scribes — and what’s the hallucination risk?

Accuracy is where “honesty is the product.” Modern LLM-based scribes are good enough that clinicians adopt them at scale — and they still hallucinate in ways that can be clinically dangerous. Both things are true, and a builder has to design for the second one.

What “hallucination” looks like in a clinical note

The dangerous failures aren’t typos. They’re:

• Fabricated history — a symptom, medication, or past condition the patient never mentioned.
• Phantom exam findings — the highest-risk category. Multiple studies document ambient systems recording entire physical exams that never took place. In a telemedicine context, an LLM can “complete” a note with normal findings a clinician never performed.
• Misattributed statements — putting the clinician’s words in the patient’s mouth or vice versa, often from poor speaker diarization.

Each of these can survive into a note that reads fluent and plausible — which is precisely why an unreviewed draft is a liability.

Documented rates from the literature (reported, and why they vary)

Reported hallucination and error rates vary widely because study designs and definitions vary widely. Leading platforms self-report clinical-content hallucination rates in the ~1–3% range; some analyses report averages around ~7%; and a simulation comparing five ambient-scribe platforms found a mean error rate as high as ~26% in generated notes. The npj Digital Medicine review “Beyond human ears” frames the core point well: newer LLM scribes have lower overall error rates but introduce distinct failure modes — hallucination, critical omission, misattribution, contextual misinterpretation — that create new safety challenges rather than eliminating old ones.

The honest read for a builder: don’t design around a single headline percentage. Design around the fact that fluent, plausible, wrong content will be generated some of the time, and that catching it is the clinician’s job — which your product must make easy.

Mitigations that actually help

• Mandatory clinician review and attestation — the primary control. Everything else is secondary to this.
• Narrow-scope prompting — instruct the model to document only what was said and to leave sections empty rather than fill them; the phantom-exam failure comes from models “completing” notes.
• Confidence flagging — surface low-confidence or unsupported statements for extra scrutiny rather than presenting the whole note as uniformly reliable.
• Grounding and provenance — keep the note’s claims traceable to the transcript, so the clinician (and later an auditor) can check a finding against what was actually said.
• Audit trails — log the audio, transcript, draft, edits, and attestation so you can reconstruct any note’s history.

How do you actually integrate an AI scribe without breaking HIPAA?

Pulling it together, here’s the architecture checklist we’d hold a build to (for the general pattern of adding AI to a HIPAA system beyond scribes, see our HIPAA-compliant AI integration guide):

• BAA chain complete — a signed BAA covering the specific service at every PHI-handling hop (media transport, STT, LLM, note storage, EHR), audio modality confirmed in-scope where you stream live audio.
• Encryption in transit and at rest — TLS/SRTP on the wire, encryption on every store of audio, transcript, and note.
• Consent as a first-class workflow step — explicit patient consent to AI scribing captured at the visit, timestamped, logged, tied to the encounter (not boilerplate in an intake form).
• Clinician review + attestation enforced — the draft cannot reach the chart or a bill without an explicit, logged sign-off.
• Audit logging — full lineage from audio → transcript → draft → edits → attested note.
• Data retention and deletion policy — decide and enforce how long audio and transcripts live; the least PHI retained for the shortest necessary time is the safest posture.

Mapping this checklist against your own platform and want a second set of eyes on the PHI flow? That’s exactly the free call we offer (details at the end of this piece). And if you’ve already shipped a scribe integration and the Sharp HealthCare case has you wondering about your own exposure, that’s a conversation too.

Build vs. buy

• Buy a vendor scribe (Abridge, Nuance DAX, Suki, DeepScribe and others) when you want a turnkey documentation feature, your EHR integration matches their supported set, and their BAA cleanly covers your PHI flow. You’re accepting their pipeline and their data-handling in exchange for speed.
• Build/integrate a custom pipeline when the scribe must live natively inside your own telemedicine platform, tap your own WebRTC media path, meet a compliance regime a packaged vendor doesn’t (e.g., specific EU/GDPR or German KBV constraints), or when you need control over the model, prompting, and data residency. This is the harder path, and it’s where the PHI-map discipline in this article earns its keep.

Most teams that come to us aren’t choosing purely one or the other — they’ve bought a piece, hit the integration/compliance reality at the seam between the AI layer and the live media layer, and need someone who understands both.

Where Trembit’s dual expertise fits

The reason this problem is hard is that it lives at an intersection: the compliant real-time video/voice transport and the AI layer on top of it are usually two different specialties, and the compliance gaps hide in the seam between them. Trembit works on both sides of that seam — one of the few teams that does. We build HIPAA- and KBV-compliant telemedicine platforms — the video transport, the encryption and BAA chain, the storage — and we integrate AI into the live media path on top of it — the clinical-AI engineering an ambient scribe demands — across 50+ real-time video/voice builds. Our KBV certification for German psychotherapy telemedicine is rare among WebRTC teams, and it reflects the kind of operational-compliance discipline an ambient scribe demands: consent capture, data-protection controls, and provable review workflows, not just working code.

A concrete pattern from this kind of work (anonymized): on a KBV/HIPAA-grade telemedicine build, we’ve put the SFU-side audio fork described earlier inside the compliance boundary — the media server in the PHI path under BAA, consent captured as a runtime workflow step rather than a line in the terms of service, and the note gated behind an explicit clinician attestation before any write. The failure that surfaces late is rarely the model. It’s the seam — an audio fork that carries PHI to a vendor endpoint the BAA didn’t actually cover for that modality, or a consent step that existed in the terms of service but never in the runtime workflow. Getting the model to draft a note is the easy 20%. Making the data flow around it defensible is the 80% this article is about.

What does an AI scribe cost to run?

Pricing context, not the core of the decision. Vendor SaaS scribes generally run from roughly $40 per clinician per month on budget/capped tiers up to $700+ per clinician per month for enterprise plans with deep EHR integration. For comparison, a human medical scribe runs roughly $32,000–$42,000 per provider per year, while most AI tiers land under ~$1,500/year for a small practice.

A custom build/integration doesn’t map to a per-seat SaaS number — the cost is engineering (pipeline, consent workflow, EHR integration, compliance work) plus ongoing STT/LLM API usage. As a rough order of magnitude to size the conversation — not a quote — the compliant-integration engineering typically lands in the tens of thousands of dollars, driven far more by the consent/BAA/audit-workflow work than by the model plumbing, plus per-minute STT/LLM usage that scales with call volume. You’d build custom when the per-seat vendor math doesn’t work at your scale, when no vendor fits your compliance regime, or when the scribe must be a native part of your own platform rather than a bolt-on. For a deeper cost breakdown of running a real-time AI voice pipeline, see our voice-AI cost guide.

FAQ

Is an AI clinical scribe HIPAA compliant?
It depends entirely on the integration, not the tool. A scribe is HIPAA compliant only if every vendor touching PHI in its pipeline — speech-to-text, the language model, note storage — is covered by its own signed BAA for the specific service in use, with encryption in transit and at rest and a real consent and review workflow around it. It’s only as compliant as its weakest uncovered hop. (Informational, not legal advice; verify with your compliance counsel — as of July 2026.)

Do patients need to consent to AI scribing during a telehealth visit?
Yes as a matter of good practice everywhere, and as a matter of law in roughly 12 US two-party/all-party consent states as of July 2026 (CA, CT, DE, FL, IL, MD, MA, MT, NH, OR, PA, WA — verify current state law, this list drifts). An ambient scribe is legally a recording device, so recording-consent statutes apply on top of HIPAA. The Sharp HealthCare class action (filed Nov 2025) alleges 100,000+ patients were recorded without valid consent using boilerplate language — the lesson is that consent must be a real, logged workflow step, not a checkbox.

Can an AI scribe’s note go straight into the medical record without a clinician reviewing it?
No. The AI produces a draft; a licensed clinician must review, edit, and attest before it becomes part of the chart or supports a bill. ONC’s HTI-1 framing treats these as clinician-review tools by design, and clinician review is your primary defense against hallucinated content entering the record.

How accurate are AI clinical scribes?
Accurate enough for large health systems to adopt at scale, but not accurate enough to trust unreviewed. Reported hallucination/error rates vary widely by study design — from ~1–3% self-reported by leading platforms up to ~26% in one multi-platform simulation. The dangerous failures are fabricated history and phantom exam findings, not typos. Mandatory clinician review is the main mitigation, backed by narrow-scope prompting, confidence flagging, provenance, and audit trails.

Does the OpenAI Realtime API work for HIPAA-covered AI scribing?
Not automatically. A vendor’s BAA covering its text API does not necessarily cover its real-time streaming audio modality — and a scribe wants live call audio. Confirm the audio endpoint specifically is in-scope. We cover the details in a dedicated piece — the OpenAI Realtime API’s audio-modality HIPAA gap.

What does it cost to add an AI scribe to a telemedicine platform?
Vendor SaaS scribes run roughly $40–$700+ per clinician per month depending on tier and EHR-integration depth. A custom build/integration isn’t a per-seat number — it’s engineering effort plus ongoing STT/LLM API usage, and it makes sense when no vendor fits your compliance regime or the scribe must be native to your platform.

Talk it through with people who’ve built both layers. If you’ve been handed “add an AI scribe to our video visits” and you’re staring at the PHI map, book a free 30-minute technical call with our team: bring the specific decision you’re stuck on — where to fork the audio, which hop your BAA doesn’t actually cover, how to make consent a real workflow step — and we’ll pressure-test your approach against how we’ve built HIPAA- and KBV-compliant real-time systems. No deck, no pitch.

This article is informational and technical guidance, not legal or compliance advice. Compliance rules, state consent law, vendor BAA scope, and CMS billing policy change without notice. Confirm current requirements with your own compliance and legal counsel and current HHS/state guidance before handling protected health information. Last updated: July 2026.