Short answer: Medical coders should not dictate codes, modifiers, or account numbers. Dictate the prose instead: provider query letters, appeal narratives, audit findings, and education notes. Keep code entry on the keyboard, and use a personal dictionary so recurring clinical terms transcribe correctly every time.
Ask someone outside the field what a medical coder does all day and they will describe code lookup. Ask a coder and you get a different answer, because a large share of the day is not assigning codes at all. It is writing prose about why a code was or was not assigned, to an audience that can push back.
Provider queries. Denial appeals. Audit findings and the education notes that follow them. Escalation emails to a coding manager. Rebuttals to a payer's clinical reviewer. Documentation improvement feedback that has to be compliant, neutral, and non-leading. All of it is written English, all of it has to be defensible, and almost all of it gets typed into a text box at the end of a long day of chart review.
That prose is where voice typing earns its place in a coding workflow. Not the code entry, which should stay on the keyboard for reasons covered below, but the paragraphs around it.
The math, and why it applies unevenly
The average adult types around 40 words per minute. Professional typists land in the 80 to 100 range, and plenty of experienced coders are up there from sheer volume of keyboard hours. Most people speak at 130 to 150 words per minute in ordinary conversation.
The temptation is to read that as a flat three-times speedup. It is not, and pretending otherwise sets people up for disappointment. Speech is faster than typing for continuous prose where you already know roughly what you want to say. It is slower, or simply wrong, for anything structured: a code, a modifier, a dollar amount, an account number.
Coding work is a mix of both. The realistic gain is not "everything three times faster." It is that the twenty minutes you spend composing a carefully worded query letter becomes seven or eight minutes, and the code entry itself takes exactly as long as it always did. Across a full queue of queries and appeals, that difference compounds into real time back.
What is actually worth dictating
Provider query letters
A compliant query is a small piece of technical writing. It has to present the clinical indicators from the record, ask an open question, avoid leading the provider toward a particular answer, and stay neutral in tone. Coders write these constantly and they are precisely the kind of writing where the hard part is phrasing, not typing.
Speaking a query draft works well because the constraints are about wording, and wording is what your voice is good at. You already know what the record shows and what you need to ask. Dictate the clinical indicators paragraph, dictate the question, then read it back on screen with your compliance lens on and tighten anything that drifted toward leading. That review pass is not optional, and it is the same pass you would do on a typed draft.
Where dictation genuinely helps is that a spoken first draft tends to be more natural and less clipped than a typed one. Typed queries under time pressure get terse in ways that read as brusque to the provider receiving them. A spoken draft usually needs trimming rather than warming up.
Appeal and reconsideration narratives
Appeal letters are the longest prose most coders produce. A first-level appeal explaining why the documentation supports the assigned code can run several hundred words, and it has to walk through the clinical picture in an order a reviewer will follow.
This is the single best use of dictation in the whole workflow. You have the record open, you know the argument, and the bottleneck is transcribing an argument you have already constructed in your head. Speak the narrative in one pass, then edit. Keep the code references, the date spans, and the claim numbers typed.
Audit findings and coder education
If you do internal auditing or quality review, the finding itself is a short structured entry and the explanation is prose. "The documentation supports X rather than Y because..." is a sentence you write dozens of times a month with different content each time. Dictating the explanation and typing the codes splits the work along exactly the right seam.
The education note that follows an audit is often longer than the finding and matters more, because it is what actually changes behavior. Those tend to get written thinly because nobody has time. Speaking them is the difference between two sentences and a paragraph that a coder can learn from.
Everything around the work
Emails to the CDI team. Notes to a physician advisor. Comments in whatever workflow tool routes accounts. Status updates to a supervisor about a backlog. Handoff notes at the end of a shift. None of this is glamorous and collectively it consumes a surprising amount of the day.
What you should keep typing
Being honest about this matters more than any productivity claim, because getting it wrong in a coding context has consequences beyond an awkward sentence.
- Codes and modifiers. Alphanumeric strings with meaningful punctuation are the worst case for speech, and a transposed character in a code is not a typo, it is a wrong claim. Enter these with the keyboard, in the encoder, where your own validation logic catches errors.
- Account numbers, claim numbers, and medical record numbers. Same reasoning. Copy and paste them, or type them. Never speak them and never trust them unverified.
- Dollar amounts and units. Charge amounts, allowed amounts, and quantities all carry decimal risk. Type them.
- Dates in structured fields. Dictating a date of service into a prose sentence is fine. Dictating one into a date field that expects a particular format is asking for a reformatting problem.
- Anything inside a field with its own validation you cannot see. If the system silently reformats what you enter, verify before you move on.
The rule is simple enough to hold in your head: if it is a sentence, speak it; if it is an identifier, type it. Everything else follows from that.
Terminology, and the thing that makes or breaks this
Generic dictation handles ordinary English well and struggles with the specific vocabulary of any specialist field. Coding vocabulary is dense with terms that sound like other words, abbreviations that are pronounced as letters, and eponyms that no general dictionary contains. Drug names are a category of their own, and we cover those separately in the post on medical dictation with drug names and ICD-10 terminology.
The practical fix is a personal dictionary. Voice Keyboard Pro calls this Smart Vocabulary: you add the terms you actually use, with replacement rules for how they should appear in your text. Add your facility's name, your payers, the specialties you code for, the clinical terms that recur in your specialty, and the abbreviations your department expects in written form.
The setup effort is smaller than it sounds, because coding vocabulary is heavily repeated. A cardiology coder uses a few dozen terms constantly and encounters the long tail rarely. Twenty minutes building a list of the terms you say every day removes most of the friction permanently. If you specialize, you can maintain the list per specialty and adjust when you move service lines.
There is a broader point here about how custom vocabulary changes dictation accuracy: the difference between dictation that feels unusable and dictation you rely on is almost always vocabulary, not the transcription itself.
Setting it up on a Mac
Voice Keyboard Pro runs in the menu bar. You choose a hotkey, hold it while you speak, and release. The finished text appears at your cursor in whatever application is in front of you: the encoder, the workflow queue, Outlook, a Word document, a browser form. There is no separate dictation window and nothing to copy across, which matters when you are working across two monitors with a chart on one side and a form on the other.
A practical pattern that fits coding work well:
- Review the chart and decide the coding question, as you always would.
- Click into the query or appeal field and confirm the cursor is there.
- Hold the hotkey, speak the narrative as one continuous thought, release.
- Read it on screen and edit for compliance, neutrality, and precision.
- Type the codes, dates, and identifiers by hand.
Step four is not overhead you are adding. It is the review pass you were already doing, applied to a draft that took a quarter of the time to produce.
Meeting Mode for coding committees and payer calls
Coders sit in more meetings than the job description implies: CDI huddles, denial review committees, payer calls, coding update sessions when guidelines change. Meeting Mode captures those with speaker detection and produces AI notes, which is useful when the action item assigned to you in minute thirty-eight is the thing you actually needed to remember. Calendar meeting detection means it can prompt you when a scheduled meeting starts rather than relying on you to remember to begin.
Recording any conversation involving patient information or payer negotiation is a policy question before it is a technical one. Check with your compliance team and follow whatever your organization requires about consent and recording, the same as you would for any other capture tool.
On the iPhone
Voice Keyboard Pro on iPhone is a custom keyboard with a built-in mic button, so it works in any iOS application. For coders working remotely or splitting time between sites, this covers the gaps: replying to a manager's message about a held account, capturing a thought about a pattern you noticed before it evaporates, drafting the outline of an appeal on the train so the writing at your desk starts from something.
Voice Edit is worth knowing about. Rather than tapping into the middle of a paragraph to fix a word, you speak the change you want and it is applied. On a phone keyboard, where precise cursor placement is genuinely awkward, this saves more time than it sounds like it should.
Two-way translation while dictating covers 24 languages, which is relevant in departments that handle correspondence in more than one. Swipe typing is there for the moments when speaking is not appropriate.
Privacy, and being accurate about it
This deserves a straight answer rather than a reassuring one, because coders work adjacent to protected health information all day and are trained to be skeptical of tools that touch it.
Voice Keyboard Pro's server stores only operational pings. No audio is retained and no transcript content is stored on the server. Your transcribed text goes to your cursor and lives wherever you put it.
That is a fact about the product, not a compliance determination for your organization. Whether any dictation tool may be used with PHI in your environment is a decision for your privacy officer and your employer's policy, and it depends on agreements and controls that vary by organization. Ask before you dictate anything patient-identifying. The safe starting point, and the one most people end up at anyway, is to use voice for the prose that carries clinical reasoning without identifiers and keep identifiers on the keyboard. That happens to be the same rule the accuracy argument already pointed to.
The ergonomic argument, which is not secondary
Coding is a high-volume keyboard job, frequently eight hours of it, frequently in a home office with equipment nobody assessed. Repetitive strain is an occupational reality in this field rather than a hypothetical, and coders who develop wrist problems often face a genuine question about whether they can continue in the role.
Voice does not eliminate keyboard use in coding work and this post has argued it should not. But shifting the prose portion off the hands meaningfully reduces total keystrokes per day, and the prose portion is substantial. For anyone already managing symptoms, that shift is worth more than the time saved. The same calculation applies across other documentation-heavy clinical roles, which we look at in the pieces on voice to text for nurses and voice typing for medical scribes.
Getting started without disrupting a queue
Do not convert your whole workflow on a Monday morning with a backlog waiting. Start with one category of writing where the stakes are lowest and the volume is highest.
Internal notes are the right place to begin. Nobody outside your team reads them, errors cost nothing, and you produce enough of them to get a real feel for the rhythm within a day. Once speaking a paragraph feels normal rather than self-conscious, move to provider queries, where the writing is short and you review every word anyway. Appeals come last, because they are longest and most consequential, which also makes them where the time savings are largest once you trust the process.
Expect the first day to feel slower. Speaking prose that will be read is a different skill from speaking conversationally, and most people need a short adjustment before they stop narrating punctuation and start just talking. It is typically a day or two, not a week.
The rule that makes voice work in coding: if it is a sentence, speak it. If it is an identifier, type it.
There is a free tier with daily limits, which is enough to run the internal-notes experiment described above and decide for yourself. Pro is $4.99 a month or $34.99 a year. The relevant comparison is not against the price of other software. It is against what an hour of your queue time is worth, and how many hours a week currently go into typing paragraphs you could have spoken.
The words land at your cursor in whatever app you are already in — Mail, Slack, Word, a browser form. No dictation window, nothing to copy across.
Free forever for casual use · Apple Silicon & Intel