Header - For a year, AMA has circulated larger and larger revisions of Appendix S, its position on software-intensive services. Here, I argue not for or against specific redlines (which may be copyright or confidential) but rather I discuss some general principles.
###
In 2023, the AMA added an “Appendix S” to the AMA CPT
procedures and codes handbook. Appendix
S does not define what advanced software is, but when it occurs, Appendix S
proposes that each instance of such software services can be classified as “Assistive,
Augmentive, or Autonomous.” In 2025 and
now 2026, AMA has proposed multiple versions of a revised – and now very
heavily revised – Appendix S.
In this note, I’m not commenting on particular changes (which
may be copyright or confidential) but on the overall themes and attendant
problems. The main references, then,
are the current public Appendix S (fn 1).
I also recommend readers see a publication about Appendix S (fn 2) and a
recent article by Dr. Richard Frank (fn 3).
AMA may later introduce a new coding category CMAA. (fn 4).
From my perspective as a physician-MBA working in strategy
consulting, here are some of the important, but less-discussed challenges.
##
First, readers need a clean copy!
While the latest of many dense revisions belongs to
AMA, I don’t think it violates confidentiality to say it is virtually
unreadable, a dense mat of revisions, strikeouts, inserts, and more revisions
atop one another. At a minimum, AMA
should also issue a CLEAN version of their most recent proposal at any given
time.

Second... Start over??
The extent of revisions suggests that piling many
layers of revisions on top of the original is no longer productive or
optimal. For example, the US Constitution
is not a 99% redline of the Articles of Confederation, they wrote a new
document. It would likely be more
fluent and lucid to simple write a new document and not have a hodgepodge of preserved
word pairs or phrases under mountains of redlining.
Third... Living with A, A, and A.
We should address whether the continued use of an
early idea, “assistive, augmentive, autonomous” makes sense. AMA attempts – and it’s nearly impossible –
to address disjunct concepts at once, such as detection, parameter generation,
interpretation, physician involvement, and machine-initiated actions.
We may be better calling things Software Services Type 1,
Type 2, Type 3. (This is exactly what App S already does for the 3 divisions of Autonomous! Numbered not named, letting you shape the meaning exactly as you want to. Or, Category III codes are just called "that," and then defined.)
Commandeering existing
adjectives that don’t naturally fit together (but happen to have clever
alliteration) may confuse more than help, by pulling in legacy meanings of the
words chosen.
Fourth,Beta Testing as a Priority.
The projects needs much more than a couple examples
out of the universe of software
solutions. Machines, and computer
programs, need extensive “beta testing” which in this case might be 20 or 30
examples fed into the most current revision.
Do 4 experts independently agree which of the 20 or 30 examples belong
as subjects of Appendix S? Likely
not. (AI is not defined, etc). How high is the independent reviewer agreement
on how the 30 examples parse in to 3 buckets (A1, A2, A3)? Likely the kappa statistic for agreement would
be distressingly low. This kind of firetesting or beta-testing points out the weak spots, to allow fixing. But we have no
data.
Fifth, a Decision Tree = Logic.
A logical, structured approach to using the concepts might be very helpful. Take software X, and ask first, does it fit “augmentative?’ If yes, stop. If not, then there are only two choices: is
it assistive or argumentative? Bringing
algorithmic structure to the usage of the appendix might be helpful.
Sixth, No Defining AI - Was That Really a Good Idea?
And this circles back to the beginning. Appendix S purports to subtly categorize and subcategorize certain types of software-intensive services that qualify for this treatment.
We
would assume and hope with high precision in the results, ...for some cloudy universe of kind of software-intensive
services like AI and Machine learning, while not defining at all what does or
doesn’t come into the domain of Appendix S is the first place.
Yet we expect Appendix S rules to work ono all those inputs, precisely and consistently. That may be crazy and lead to all kinds of downstream
problems that we aren’t facing.
___
I believe that Appendix S was designed originally for
software-only services. If so, we need to codify that. We should
state clearly that physical services (like whole genome sequence) that may use
a lot of AI, remaining coded based on the physical service component (81425,
genome) and not pulled onto CMAA by the AI within. For example, WGS may yield a variant of
unknown significance VUS (C>T), which is resolved as benign by AI proteomic
software that validates there is no protein configuration change. I would expect the service is still WGS with resolution
of variants, billed as 81425. I would be
chilled if the WGS service got extracted to a payor-not-recognized code over in
CMAA, because the service contains AI in part.
At some point Appendix S should make this clear, the physical part of
the code governs coding and a folded-inside AI component does not drag
everything onto the CMAA listing.
___
1. https://www.ama-assn.org/system/files/cpt-appendix-s.pdf
2.
Frank, 2022, PMID 36463327. https://pmc.ncbi.nlm.nih.gov/articles/PMC9719561/
3. https://www.frankhealthcareadvisors.com/post/cpt-appendix-s-the-missing-link-between-ai-innovation-reimbursement-1
4. https://www.ama-assn.org/practice-management/cpt/cpt-codes-offer-language-report-ai-enabled-health-services [CMAA]