Inside Heidi's Templating System: How "Round Brackets" Are Quietly Solving Note Bloat

Most ambient AI scribe demos look the same. A clinician talks. A transcript appears. A note generates. The note is reasonably accurate, the format is generic, and the demo ends. What separates a tool a physician will actually adopt from one they will abandon by week three is almost never the headline accuracy number. It is whether the output reflects how they document, at the level of phrasing, emphasis, structure, and what gets omitted entirely.

That nuance is what Mehul Akhouri, one of Heidi's commercial leads, spent most of his demo time on during Offcall's recent AI Residency webinar. The overview article mentioned Heidi's templating capabilities at a high level. But the specifics, particularly the distinction between what Mehul called "square brackets" and "round brackets," are the operational detail that explains why Heidi sees what he described as "20, 30, 40% higher adoption rates" in complex environments.

It is worth unpacking how it actually works.

Resources:

• Session slides
• Dr. Michael Hobbs' AI 101 Guide
• Heidi Health — AI clinical documentation

This session is part of Offcall's AI Residency series. The previous session covered AI fundamentals. Sessions 3 and 4 cover cutting through the hype and vibe coding for clinicians.

The two-part template anatomy

Most documentation tools treat templates as fill-in-the-blank forms. Data goes in slots. The slots are static. The output is whatever the slots happen to capture.

Heidi's templates have two distinct components, and the second is where the leverage lives:

• Square brackets [ ] are the placeholders. These define what data points or elements of the encounter belong in which section of the document. This is the part most people think of when they hear "template."
• Round brackets ( ) are the instructions to the model. This is where, as Mehul put it, "we can actually begin to communicate to Heidi as if it's a human being, as if it's my human scribe sitting with me in the room."

That second category is what turns a template from a form into a working document.

What the round brackets actually do

The round brackets carry instructions about behavior rather than content. Mehul ran through several examples in a comprehensive psychiatric intake template:

• Conditional inclusion. "I'm actually telling Heidi to only include them if they were discussed, otherwise omit them entirely." The note doesn't pad out empty sections with "not assessed" or "deferred." Sections that didn't happen don't appear.
• Format control. "I've got my reason for visit and narrative pros format." A clinician who wants prose gets prose. A clinician who wants bullets gets bullets. The template carries that preference.
• Length control. "I've got my HPI summarized in two to three sentences at the top. Maybe we're working in an inpatient setting and we want to be doing these handovers." Different settings, different brevity demands.
• Stylistic preferences. Anything from voice (formal versus conversational) to emphasis (always foreground medication interactions) to specific phrasing conventions used by the practice.

The cumulative effect, in Mehul's framing, is "minimizing any kind of note bloat," which is the documentation problem that most clinicians actually live with.

Why this changes adoption, not just output

Mehul's claim that more flexible templating drives meaningfully higher adoption is worth taking seriously. The reason is straightforward: an ambient scribe that produces a competent generic note still asks the clinician to edit it into the form they actually use. That editing is friction. Multiplied across 20 patients a day, the friction is enough to make a lot of clinicians quietly stop using the tool.

A template system that captures the practice's actual documentation conventions, including the unwritten ones, collapses that editing work. The note that comes out is the note that gets signed.

The other piece that Heidi has built around this is a layered template library: an individual clinician's templates, the team's organizational standards, and a verified community library with thousands of templates across specialties and jurisdictions. A solo practitioner does not have to start from scratch. A health system can enforce documentation consistency without building everything in-house.

The handoff: from template to ecosystem

Heidi's templating philosophy is actually a wedge into a larger architectural argument. Mehul was direct about the strategy: "The goal for us was never to end at the scribe. It was just kind of the most pertinent entry point for us into the clinician's workflow."

Once visits are being captured ambiently, the same context that powers the note can power other things. The webinar walkthrough showed three of them:

• Tasks. If the clinician told the patient during a visit that they would follow up in two days, that becomes a queued task automatically.
• Communications. That follow-up can be executed by what Mehul called a Heidi "AI agent," a bot configured with an objective ("check on the patient's tinnitus symptoms") that calls or messages the patient and reports back.
• Evidence. A clinical evidence query made inside Heidi automatically incorporates the patient's transcript, note, and historical visits as context. The same query in a standalone tool would require manually reconstructing all of that.

The connective tissue here is the templating layer. Because the template instructs Heidi about what mattered in the encounter and how to structure it, downstream features can act on that structure without requiring the clinician to manually shuttle context between apps.

The killer demo: prior auth letters with denial-risk flagging

The example that crystallized this for the audience was a workflow Mehul ran live near the end of the demo. The setup: a patient with Crohn's disease, a need for a prior authorization, and the question of which elements of the case would create denial risk under the practice's specific insurance contracts.

Mehul toggled off external evidence sources, leaving only the practice's internal documents (mock insurance contracts in the demo, real ones in production). He prompted Heidi to draft the prior auth letter and flag denial risks based on those internal contracts.

The output was a draft letter plus a ranked table of denial risks, organized from high to low, with references back to the specific contract clauses driving each risk.

"All these complex bundling rules, all these complexities that lie in our internal documentation and knowledge bases that we've got whole staffing teams dedicated to spend hours a day doing these back and forths. We're equipping them with this power."

That workflow, prior auth drafting with contract-specific denial risk analysis, is the kind of operational lift that pays for the platform several times over in a busy specialty practice. It is also a workflow that does not exist in most ambient scribe demos because most ambient scribes stop at the note.

What clinicians evaluating ambient platforms should ask

The takeaway for clinicians shopping for ambient documentation is that the depth of the templating system is a leading indicator of whether the platform will hold up over time. The questions worth asking:

• Can templates carry instructions, not just placeholders?
• Can sections be conditionally included or omitted?
• Can templates encode stylistic and length preferences?
• Is there a verified community library to start from?
• Does the same context that powers the note also power downstream workflows?

If those answers are no, the tool is a transcription engine. If they are yes, it is an operating layer.

To see Mehul walk through the full Heidi demo, including the live prior auth workflow, watch the complete webinar here: