I gave Chat GPT some drafts of AMA CPT Appendix S for software services and asked it to make the best re-write it could, aiming to fix a number of problems. (The copy below is its 2nd attempt to make this rewrite.)
###
Appendix S - ReWritten Anew, by Chat GPT
Taxonomy for Software Output in Medical Services and Procedures
This taxonomy provides guidance for the use of the terms assistive, augmentative, and autonomous in CPT code descriptors and related procedural language for medical services and procedures that include software-enabled analysis.
This taxonomy provides guidance for the use of the terms assistive, augmentative, and autonomous in CPT code descriptors and related procedural language for medical services and procedures that include software-enabled analysis.
Appendix S describes the clinical role of software output in medical services and procedures. It does not define “artificial intelligence,” “machine learning,” or other general classes of software. The relevant question is not whether a product is labeled “AI,” but what the software output does in clinical care.
A term from Appendix S should be used only when the software output is relevant to the diagnosis, cure, mitigation, treatment, or prevention of disease or other conditions and is pertinent to patient management in the clinical context described by the code. Software used only for administrative, financial, scheduling, workflow, or general productivity purposes does not fall within this taxonomy solely because it is used in health care.
The terms in Appendix S describe the software-enabled analytical role at issue. In some cases, that role may correspond closely to the reportable service. In other cases, it may describe only one component of a broader service. Accordingly, Appendix S does not by itself determine whether a service is separately reportable or require reclassification of an already coded physical service or device solely because software is used within it.
Use of a term from Appendix S should be supported by evidence appropriate to the role of the software output in clinical care and consistent with CPT code criteria. Depending on the claimed function of the software output, such evidence may include technical validity, analytical validity, clinical validity, and, when appropriate, evidence of impact on patient management or clinical utility.
For purposes of this taxonomy, a parameter is a quantitative or categorical output derived by software and reported for clinical use, such as an index, score, classification, risk estimate, measurement, or other metric. Not every transformed output is a parameter. The key question is whether the output is a distinct reportable result used in clinical care.
For purposes of this taxonomy, automatic or automatically means that software derives its output without concurrent human involvement in the analytic process from input to output. Automatic derivation may occur in either augmentative or autonomous services and does not, by itself, establish autonomous status.
Assistive
Services and procedures performed by software for the physician or other qualified health care professional (QHP) are assistive when the software output detects, identifies, highlights, prioritizes, or otherwise brings clinically relevant data to the attention of the physician or other QHP without deriving a distinct reportable parameter and without independently generating a clinical interpretation or conclusion.
Assistive software supports physician or QHP performance. It may improve accuracy, precision, consistency, efficiency of review, inter-observer variability, or timeliness of recognition of clinically relevant data, while the reportable outcome of the primary clinical service may remain unchanged.
When the service is reported as a professional service, the output from assistive software requires physician or other QHP interpretation and report. Assistive software does not independently establish a diagnosis, recommendation, or management action.
Assistive outputs may include indications such as the presence, location, or salience of clinically relevant data. Terms such as “likelihood of,” “suggestive of,” or “risk for” may be consistent with assistive output only when they serve to draw attention to clinically relevant data rather than provide a definitive interpretation, conclusion, or management recommendation.
Evidence supporting assistive software should be appropriate to the claimed role of the output in clinical care. Where the assistive output does not itself alter the reportable clinical conclusion, technical or analytical validation showing benefit to clinical performance may be sufficient. Where the output implies a clinically significant inference, additional clinical validation may be appropriate.
Augmentative
Services and procedures performed by software for the physician or other QHP are augmentative when the software output derives a distinct quantitative or categorical parameter that is qualitatively different from the input and is used in clinical care, but does not independently provide a definitive clinical interpretation, conclusion, or management recommendation.
An augmentative output must be more than a restatement, summation, averaging, display, transmission, or descriptive presentation of input data. It must provide a distinct reportable result, such as a scale, index, classification, measurement, score, probability estimate, risk estimate, predictive measure, prognostic measure, mapping output, or other metric used in clinical care.
Augmentative output is clinically meaningful when the derived parameter contributes to patient management in the clinical context described by the code. Clinical meaningfulness may be supported by equivalence to a metric already used in current practice, consistency with clinical practice guidelines or accepted clinical frameworks, or evidence that a novel output has clinically relevant impact on patient management.
For augmentative services, evidence should show more than technical or analytical performance alone. It should support the clinical relevance of the derived parameter for the patient population, service, and clinical context described by the code.
Software with augmentative outputs may operate automatically or may require physician or other QHP interaction during the analytic process. The related physician work may be described by the same code, captured in another code, or incorporated into a broader service, depending on code structure.
Note: The presence of an augmentative output within a broader coded service does not by itself require separate reporting of the software function or reclassification of the broader service.
Autonomous
Services and procedures performed by software for the physician or other QHP are autonomous when the software independently generates a clinically meaningful interpretation, conclusion, recommendation, or management action from clinical input data without concurrent physician or other QHP involvement in the analytic process.
Autonomous output goes beyond derivation of a parameter alone. It independently interprets data or derived parameters and produces a clinically operative result, such as a definitive diagnostic conclusion, a specific management recommendation, or initiation of a management action.
Clinical meaningfulness for autonomous output should be supported by evidence appropriate to the role of the software in patient care. Such support may include consistency with clinical practice guidelines or accepted clinical standards, direct evidence of impact on patient management, or other evidence sufficient to support the degree of autonomy being described.
Automatic derivation is necessary but not sufficient for autonomous classification. A service is not autonomous merely because software operates automatically. It is autonomous when the software independently provides the clinically operative interpretation, conclusion, recommendation, or action.
There are three levels of autonomous medical services and procedures:
Level I
The output of autonomous software includes a definitive diagnostic conclusion and/or a specific management recommendation. The conclusion or recommendation is contestable and requires physician or other QHP judgment to implement, reject, or otherwise act upon it.
Level II
The output of autonomous software includes initiation of a management action based on the software’s interpretation or conclusion, but the service provides a reasonable opportunity for physician or other QHP review, interruption, or override before the action is carried out.
Level III
The output of autonomous software includes automatic initiation and continuation of a management action based on the software’s interpretation or conclusion, such that physician or other QHP oversight occurs at a supervisory level rather than through case-by-case concurrence before each action. Level III services require ongoing physician or other QHP oversight appropriate to the clinical circumstance and the management action being performed.
Note: Autonomous classification describes the role of the software output in the service at issue. It does not by itself require that a broader physical device, procedure, or other already coded service be separately reclassified or reported under a software-specific code family solely because autonomous software is embedded within that service.
Summary Table
| Assistive | Augmentative | Autonomous | |
|---|---|---|---|
| Primary role of software output | Detects, highlights, prioritizes, or otherwise brings clinically relevant data to attention | Derives a distinct quantitative or categorical parameter used in clinical care | Independently interprets data or derived parameters to generate a clinically operative conclusion, recommendation, or action |
| Distinct reportable parameter derived by software | No | Yes | May include derived parameters, but autonomous status depends on the independent interpretation, conclusion, recommendation, or action |
| Independent clinical interpretation or conclusion by software | No | No | Yes |
| Machine-initiated management action | No | No | May occur in Levels II and III |
| Physician or other QHP interpretation/report | Required for the professional service when applicable | May be required, or may be incorporated into another code or broader service | Not required for the autonomous output itself, although physician or other QHP oversight may still be required |
| Evidence needed | Appropriate to the claimed clinical support function; often technical or analytical performance plus benefit to clinical performance | Evidence sufficient to support clinical meaningfulness of the derived parameter in the code’s clinical context | Evidence sufficient to support the independent interpretation, recommendation, or management action claimed |
#
This version tries to do five things better than the versions taken as input.
First, it adds an entry gate;
Second, it says clearly that the taxonomy classifies the software output function, not necessarily the whole product or service;
Third, it separates automatic from autonomous more crisply;
Fourth, it removes the awkward dependence of Autonomous on a prior Augmentative construct;
Fifth, it states expressly that embedded software does not automatically pull a broader physical service into a software-only coding framework. Those are all pressure points that emerged from the current draft and the related problems in implementation.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.