Monster Snippets: How a telehealth doctor restructured his entire workflow around fewer, larger Snippets (and a gaming mouse)

We recently did a webinar with Dr. James Ries, who runs Twenty Mile Medical, a telehealth practice operating in 37 states. His Snippet setup is one of the more interesting workflows we’ve come across in a while, and we wanted to share it here because we think a few of the concepts will resonate with how some of you build your own libraries.

We’ll start with the punchline because the visual is fun: His primary clinical input device is a Razer Naga V2 Pro, the 12-button MMO gaming mouse. Each side button is mapped to a single rarely-used symbol like a tilde or a backtick. Each of those symbols is the abbreviation for one of his Snippets, which he triggers with his thumb so his eyes never leave the patient’s chart.

But the gaming mouse isn’t actually the most interesting part of his setup. It’s the Snippet structure.

What a monster Snippet is

Most TextExpander tutorials, including most of ours, walk you through building dozens of small Snippets. A signature here, an address there, a stock phrase you use often, an email template. Each Snippet does one thing. You stitch them together at expansion time by triggering several in sequence.

Dr. Ries went the other direction. He calls them monster Snippets. Each one is a single Snippet containing an entire scenario, with the fill-in dialog set up to handle every branching option that scenario might need.

So a “sinus infection visit” isn’t five small Snippets stitched together at expansion time. It’s one Snippet that, when triggered, shows a fill-in dialog with:

  • Checkboxes for which symptoms the patient is presenting
  • Dropdowns for which medications to prescribe
  • Optional sections for things like prior authorization language, allergy notes, or referral templates
  • Built-in patient communication phrasing that adjusts based on what’s selected

He picks what fits, removes what doesn’t, and the Snippet generates a complete clinical response with the introduction, assessment, prescription, patient education, and follow-up all in place.

Same pattern for psych refills. Same pattern for weight management. Same pattern for urgent care. Each scenario is one Snippet, and each Snippet is large enough to handle every variation that scenario might need.

Why this is more interesting than it sounds

The shift sounds small but it has real consequences for how you build and maintain a library.

Maintenance is easier. When clinical guidelines change for a particular scenario, Dr. Ries updates one Snippet rather than tracking down every smaller Snippet that contributes to that scenario. Fewer Snippets, fewer places for drift to hide.

Standardization is enforceable. Because the whole scenario lives in one Snippet, every required element (a screening question, an interaction warning, a follow-up instruction) is structurally present every time. There’s no “I forgot to add the prior auth language” because there’s no separate prior auth Snippet to remember. It’s already in the dialog.

Onboarding is faster. When Dr. Ries brings on a new PA, he doesn’t have to teach them which combination of Snippets to use for which scenario. They learn one Snippet per scenario, walk through the dialog, and the Snippet does the structural work.

Mistakes are caught structurally. This was the thing that surprised us most in the conversation. He said most errors in telehealth aren’t diagnostic, they’re errors of omission. A follow-up instruction that didn’t go out, a screening question that got missed, a warning that got skipped because the provider was on their fortieth visit and was tired. Monster Snippets make that structurally hard to do. The system remembers what a tired provider might not.

The gaming mouse piece

Now back to the hardware, because some of you will want this.

Dr. Ries’s button-to-Snippet mapping uses single rarely-typed symbols as abbreviations. Things like ~, the backtick, or |. He skips the obvious ones like @ and # because those come up in normal typing. His mouse software (Razer Synapse) maps each side button to send a single keystroke of one of those symbols. TextExpander picks up the symbol and expands the Snippet.

A few practical notes from his setup:

  • He uses single-character abbreviations, not multi-character ones. The mouse sends one keystroke. TextExpander handles the rest.
  • He explicitly avoids macros that send long keystroke sequences from the mouse software. Keep the mouse simple, let TextExpander do the work. This keeps Snippets editable inside TextExpander rather than scattered across multiple tools.
  • He tested a Stream Deck before settling on the mouse and didn’t love it. The labeled keys looked easier to learn, but the small motion of moving his hand off the mouse to press a key broke the workflow he was trying to protect.
  • Some of his PAs use a wireless shortcut remote held in the off hand instead. Same principle, different hardware. The point isn’t the specific device, it’s getting the abbreviation off the keyboard so the brain can stay on the work.

The Snippet pack

Dr. Ries published a public Snippet group with his actual clinical Snippets (anonymized, no PHI) so anyone can add them to their own account and study how the fill-in dialogs are structured.

Even if you’re not in healthcare, opening one of his Snippets and looking at how he organized the branching fill-ins is a useful exercise. The pattern transfers to any high-volume, high-stakes communication workflow: Customer support, sales follow-up, legal templates, agency status updates, anywhere consistent output matters more than novelty.

How we’d suggest using the Snippet pack

If you want to study the structure rather than just use the Snippets directly:

  1. Add the group to your account
  2. Open one of the larger Snippets (the patient communication or sinus infection ones are good starting points)
  3. Click into the editor and look at how the fill-in fields are organized
  4. Pay attention to which sections are optional vs. required, and how the dropdowns are structured
  5. Pick one scenario from your own work that you handle frequently with a stack of smaller Snippets, and try building a monster Snippet version

The learning curve on building one of these is real. The first monster Snippet you build will take longer than you expect. The fifth one will go faster. By the tenth one you’ll have internalized the structural patterns and the rest get easier.

Questions for you

We’re genuinely curious about how this lands here, because this community has more Snippet-building experience collectively than just about any other place we could ask:

  • Have any of you already built Snippets at this scale, or have you intentionally kept things small?
  • For those who keep Snippets small, what’s the reasoning? Easier to compose? Easier to edit? Easier to share parts of a library?
  • For those who’ve built large Snippets, what tipped you over to the larger format? Volume? Maintenance? Onboarding?
  • Has anyone else paired TextExpander with unusual hardware (gaming mice, Stream Decks, MIDI controllers, shortcut remotes, keypads)? We’d love to see your setups.

Drop a comment with your approach, and if you’re up for it, share a screenshot of one of your more elaborate Snippets in the dialog editor. We learn as much from seeing how power users build as you do from seeing each other’s setups.

Full writeup of Dr. Ries’s workflow is on the blog if anyone wants the longer version: https://textexpander.com/blog/doctor-gaming-mouse