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, 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, 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, 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 SW Type 1,
Type 2, Type 3. 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, 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. But we have no
data.
Fifth, structured use 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, and this circles back to the beginning. Appendix S purports to subtly categorize – we
would assume and hope with high precision, for some cloudy universe 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
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/
