CPT Implementation Guide: Component 6 Subsets

Overview

Purpose of the Subsets Component

This component of the handbook will inform and educate readers on what subsets are, why subsets are important, uses of subsets, the subsets development process, the importance of quality subsets, subsets challenges, subsets maintenance requirements, and what resources are available from the American Medical Association (AMA) to help with subsets development. For an introduction to Current Procedural Terminology (CPT®)[1] content, refer to Component 2: CPT® Primer.

Intended Audiences

This portion of the education handbook is relevant to all audiences, including

• Research organizations
• Local/national governments
• Local/national physician/doctor organizations/associations
• National information/standards and policy organizations
• Health information management (HIM) professionals
• Others involved with the subsets development process
• Physicians/doctors
• Analysts

Learning Objectives

After reviewing the content in the Subsets Component, the reader is expected to be able to:

• Describe what subsets are and the purpose of subsets.
• Describe why subsets should be used to adopt a terminology.
• Describe the different types of subsets.
• Identify subsets use cases.
• List existing subsets and where to download them.
• Describe the approaches to developing subsets.
• Describe the requirements of tools that are needed to develop subsets.
• Explain challenges and how to overcome them.
• Describe the need for a standard subsets distribution format.
• Describe the subsets distribution format.
• Describe the file structures, formats, and types of releases.
• Describe the different quality assurance checks and why they are important.
• Explain the process of conducting quality assurance checks on subsets.
• Describe the approaches to summarizing the contents of a subset in a succinct manner that is understandable to clinicians.
• Describe the technical implementation requirements needed to correctly and consistently implement CPT® content.
• Describe the types of changes CPT content undergoes and how that will affect subsets.
• Describe the process for maintaining CPT subsets.
• Describe how CPT® Link can be used to maintain subsets.
• Summarize the tooling requirements to support subset maintenance.
• Apply subset maintenance checks to CPT subsets.

Modules

The Subsets Component includes seven modules. These modules provide a roadmap from an introduction to subsets and subsets development, to implementation and maintenance.

Module One: Introduction to Subsets – An introduction to subsets including the definition and purpose of subsets, types of subsets, and existing subsets that are available.

Module Two: Subsets Development – Description of three approaches to developing subsets.

Module Three: Subsets Distribution Format – A distribution format specification to ensure the necessary CPT content is contained in the subsets.

Module Four: Subsets Quality Assurance and Maintenance – Quality assurance check and maintenance processes that should be conducted to ensure subsets are accurate.

Module Five: CPT® Subsets Documentation – Documentation that must be included to accompany each subset release.

Module Six: Subsets Functional Requirements – Requirements that technology and services providers must meet in order to implement CPT subsets.

Module Seven: Subsets Tooling Requirements – Requirements for tools that will be used to develop and maintain subsets.

Each module is structured as follows. Note that some sections may not apply to a specific module.

Introduction – An introduction to the topic being discussed and why it is important.

• Intended Audience – The intended audience for the module.
• Learning Objectives – A list of learning objectives that will be covered in the module.

Main Module Content – The main content may consist of five main sub-sections.

• Personnel – People who are involved in the topic.
• Tooling – Tooling and requirements that are required to apply the approach.
• Approach – The approach or methodology specific to a topic.
• Process – The interaction between personnel with other personnel and/or tooling.
• Challenges – Challenges associated with applying the approach.

Practical Use Example – An example of how the approach has been used.
 

MODULE ONE: Introduction to Subsets

Introduction

This module introduces the notion of what subsets are, the goals, scope of use, and types of subsets, as well as provides an overview of CPT® subsets that have been published by other organizations.

Intended Audiences

This module is intended for all audiences as it provides an introduction to subsets.

Learning Objectives

After reviewing the content in this module, the reader is expected to be able to:

• Describe why subsets should be used to adopt a terminology.
• Describe the different types of subsets.
• Identify subsets use cases.
• List existing subsets and where to download them.

Introduction to Subsets

Purpose of Subsets

The overall purpose of using subsets is usually to facilitate the adoption or implementation of a terminology. Clinical terminologies often contain thousands if not hundreds of thousands of terms. While the CPT content includes approximately 10,000 CPT® codes, there are nearly 28,000 Clinician Descriptors. The use of subsets can help narrow down the content in a terminology that is relevant for a specific use case. Subsets can contain just a few terms, or may contain thousands of terms, depending on the purpose of the subsets. Subsets can also help facilitate discussions with physicians/doctors about their content by demonstrating that the content is relevant to them.

Goals of Subsets

CPT content is extensive, covering a vast number of procedures and services. Any one physician is likely to report only a fraction of all procedures and services for which CPT content is available. A CPT subset should include CPT content for only those procedures and services needed for a specific purpose or group of users.

In general, the goals of subset creation are twofold:

• To make it easier for physicians/doctors to report procedures and services by making it possible for them to select from a group of CPT content for procedures and services most relevant for their physician specialty, and
• To enhance change management communication with physicians/doctors and more effectively draw on their expertise by focusing communication on procedures and services they have most experience with and in which they have the strongest interest.

Scope of Subsets

As these goals suggest, both the process of subset development and the resulting subset itself are important.
 A physician specialty subset should:

1. Contain the CPT® content for procedures and services that reflect the majority of current clinical practice for physicians in that physician specialty (or a specific use case),
2. Include all CPT content for procedures and services that physicians in the physician specialty consider to be medically appropriate, within the scope of practice consistent with their training, and
3. Include CPT content for procedures and services likely to be used more than a negligible number of times.

While the frequency of procedures and services reported in the past using an existing terminology may be useful as a guide, inclusion of a procedure or service in the subset of CPT content should not be based solely on past frequency. The procedures and services selected should represent the physician specialty’s best judgment of what is currently relevant and likely of continuing relevance.

This “current and future” orientation suggests the importance of ongoing terminology maintenance of the subset. With changes in technology, medical knowledge, and practice patterns, the list of CPT content appropriate for inclusion in the subset will change over time. The definition of a subset is never really finished. It must be reviewed and updated as necessary to reflect current clinical practice.

Roles of Physicians/Doctors

The role of physicians/doctors in subset definition is different from their role in content mapping, although both draw on clinical expertise. The role in mapping is advising on which CPT content has the “same meaning” as existing terminology. The role in subset definition is advising on the selection of CPT content for inclusion in a physician specialty subset.

Use of Subsets

A major use of CPT subsets will be within an electronic health system (eg, EMR, EHR, HIS, or HEIS as described in the CPT Framework Component) and billing systems. It will be the basis for pick-lists used by physicians/doctors for reporting procedures and services. While for most physicians most of the time the CPT content needed for reporting procedures and services will be in their physician specialty’s subset, there may be occasions when a procedure or service is provided for which CPT content is not included in the subset. In that case, the physician/doctor should be free to choose a CPT code from another physician specialty’s subset or topic specific subset (eg, immunizations).

Types of Subsets

Subsets can be grouped into categories. The categories listed here are different ways of looking at subsets and are not mutually exclusive.

1. Data capture vs data retrieval subsets
2. CPT code subsets vs Clinician Descriptors subsets
3. Physician specialty vs electronic health system-specific field subset
4. Intensional vs extensional subsets

Data capture vs data retrieval subsets

CPT® subsets may be used for data capture (eg, used by a physician at the point of care in an EMR to record a procedure or service provided) or for data retrieval (eg, used by a physician for retrieving information about patients who have received a specific set of procedures or services). In some cases, the content in these types of subsets may differ.

CPT code subsets vs clinician descriptors subsets

CPT subsets can be developed at the CPT code level or at the Clinician Descriptors level. According to the Clinician Descriptors README file:[2]

“The purpose of the Clinician Descriptors (CDs) is to clearly and specifically describe precisely the procedure or service performed by a physician/doctor or qualified healthcare professional at the point of care. CPT Clinician Descriptors will also reflect the granularity necessary to accurately describe clinically relevant information not included in the core CPT code set. As a result, many existing CPT codes will be mapped to more than one CD. These CDs will be easily understandable to the physicians/doctors or other qualified healthcare professionals who have little or no knowledge of coding and are primarily concerned with the clinical representation of the data rather than the administrative or reimbursement component of the data.”

Clinician Descriptors are more specific services or procedures that are included at the CPT code-level and are usually not synonyms.

For example, the CPT code 12016 – Simple repair of superficial wounds of face, ears, eyelids, nose, lips and/or mucous membranes; 12.6 cm to 20.0 cm includes 10 Clinician Descriptors:

1. 10000851 – Repair of wound of ear
2. 10000852 – Repair of wound of eyelid
3. 10000853 – Repair of wound of face
4. 10000854 – Repair of wound of lip
5. 10000855 – Repair of wound of mucous membrane
6. 10000856 – Repair of wound of nose
7. 10018293 – Simple repair of superficial wound of ear, 12.6 cm to 20.0 cm
8. 10018294 – Simple repair of superficial wound of face, 12.6 cm to 20.0 cm
9. 10018295 – Simple repair of superficial wound of lip, 12.6 cm to 20.0 cm
10. 10018296 – Simple repair of superficial wound of nose, 12.6 cm to 20.0 cm

It is usually prudent to include all Clinician Descriptors for a specific CPT code but there may be occasions where a specific procedure or service is not relevant for a specific subset use case.

Note: Clinician Descriptors are not unique across all CPT codes. Caution should be exercised when using Clinician Descriptors that may be ambiguous.

Physician specialty vs electronic health system–specific field subset

Subsets may be developed for physician specialties or sub-specialties (eg, cardiology or interventional cardiology) or for a more general use case (eg, immunizations, Evaluation and Management). For example, the cardiology physician specialty subset should include all procedures and services a cardiologist may conduct or perform, while an immunizations subset should contain a list of all immunization procedures and will not be limited to one physician specialty; it may be used by a general practitioner or a pediatrician to record immunizations done.

Intensional vs extensional subsets

Subsets can be developed intensionally or extensionally. Within the context of the CPT® content, the term “extensional subsets” refers to explicitly enumerating each and every CPT code and/or Clinician Descriptor. On the other hand, the term “intensional subsets” refers to specifying the CPT sections and/or subheadings that contain CPT content that is to be included in a subset. An algorithm would then be used to compute the CPT content in those CPT sections or subheadings.

For example, if an Evaluation and Management (E/M) subset is to include all E/M services, the extensional approach would be to list each E/M service individually. In the intensional approach, the CPT section E/M is used as the definition. An algorithm will then be used to identify all CPT content in the E/M section. A benefit of the intensional approach is in maintaining a subset. With each release of the CPT content, the definition of a subset can be easily re-computed to determine new CPT content to be included and existing CPT content to be excluded from the subset.

Approaches to Developing Subsets

There are three main approaches to developing subsets: adopt, adapt, and create. For each approach, a description, use, and advantages and disadvantages are shown in the following table.

Module Two describes in more detail the “create” approach to subsets development.

AMA CPT express reference coding cards

The AMA produces CPT Express Reference Coding Cards of the most frequently reported CPT content for a physician specialty. These cards can form a subset or the basis for developing a subset. As the cards only report the most frequently reported CPT content for a physician specialty, the subset may still be incomplete if the purpose is to identify all CPT content for a physician specialty. The cards available based on the 2020 CPT content release and are listed below:

The Express Reference CPT Coding Cards include only the CPT code and its Medium Descriptor but not the Long Descriptor or Clinician Descriptors. These are available as printed laminated cards or eBooks viewable in any browser or device.

 

MODULE TWO: Subsets Development

Introduction

Subsets can be developed in an ad-hoc manner or through a methodical approach that is well-documented and thoroughly vetted by clinicians and intended users of the subsets. The acceptance of a subset for use in a real-world clinical setting is dependent on understanding and trusting that the subset was developed in a reliable and methodical manner.

In Module One, we identified three main approaches for developing subsets: adopt, adapt, and create. Since adopting an existing subset in its entirety is relatively straightforward and does not require any enhancement and refinement, it is not discussed in this module. If you are adopting an existing subset, proceed to Module Five on Subsets Functional Requirements.

The subset development approach in this module consists of three cycles:

If you are creating a new subset from scratch, you should review all three cycles. If you are adapting an existing subset, you may still review Cycle 1, but Cycle 2 and Cycle 3 will be more relevant for you.

Intended Audiences

The intended audiences for this module include

• Health information management professionals – They will be managing the subsets development process and may be providing expert advice to clinicians.
• Clinicians – To gain a better understanding of the subset development process or if they are participating in the subset development process.
• Others who are involved with the subsets development process.

Learning Objectives

After reviewing the content in this module, the reader is expected to be able to:

• Describe the approaches to develop subsets.
• Describe the requirements of tools that are needed to develop subsets.
• Explain the challenges and how to overcome them.

Subsets Development

Personnel

1. Clinicians – Clinicians will be the users of the CPT® subsets and as such, are responsible for identifying and confirming CPT content for inclusion or exclusion in the CPT subsets.
2. Health information management professionals – Health information management professionals will facilitate the subsets development process by compiling an initial set of CPT® content for clinicians to review, work with clinicians to resolve any questions or issues, and compile the subsets once the reviews by clinicians are complete.

Tooling

Tooling plays a critical role in subsets development as it is not feasible to develop subsets using word processing documents or spreadsheets. Tracking and managing changes via documents and spreadsheets are not practical, especially if there are dozens of subsets and hundreds of physicians/doctors involved in the process.

Tooling requirements include:

1. Tooling must be able to create an initial subset from an input file.
2. Tooling must be able to create an initial subset based on CPT sections and subheadings.
3. Tooling must be able to assign multiple users to the same set.
4. Tooling must be able to allow users to select CPT codes and Clinician Descriptors for inclusion into or exclusion from a subset.
5. Tooling must be able to compile subsets based on various rules.

Approach

Subsets can be developed across three cycles:

Cycle 1: Subset Definition – A subset is being developed from ground zero and this cycle helps to describe possible starting points.

Cycle 2: Subset Enhancement – An initial subset has been created but additional content may need to be added to enhance the completeness of an existing subset.

Cycle 3: Subset Refinement – A subset is nearly final but additional quality checks may be done to ensure only the relevant content is included.

Cycle 1: Subset Definition

This cycle assumes you are creating a subset from ground zero and that you do not have any CPT® content identified for inclusion into a subset. If you already have a subset that you want to enhance, please proceed to Cycle 2: Subset Enhancement.

In terms of creating your own subset from ground zero, there are several options or combination of options. The two main approaches to defining a subset are:

1. Extensional Approach – CPT codes are individually enumerated for inclusion in a subset.
2. Intensional Approach – CPT sections or subheadings are used to define a range of CPT codes for inclusion in a subset.

Extensional Approach

The extensional approach is the more common approach whereby CPT codes are identified individually and explicitly enumerated in a subset. Identifying the individual CPT codes can occur via:

1. Map legacy data to CPT Content – Legacy data is mapped to CPT content in order to determine the equivalent or similar CPT codes and those CPT codes form the basis of your subset. See the Mapping Component in the CPT Implementation Framework for details.
2. Expert selection – An expert or group of experts in the area of the subsets will review CPT content and determine what should be included in your subset. As CPT® content is organized into six main sections and subheadings, the expert committee can narrow down to the content that they deem is relevant.

Depending on the purpose of the subset, the mapping team and expert selection team should comprise mapping experts, clinicians, health information management professionals, and health information technology professionals.

Intensional Approach

The intensional approach consists of expert selection of CPT sections and subheadings as opposed to individual CPT codes. CPT codes that fall within these sections or subheadings are included in the subset.

CPT Category I codes and descriptors are organized into six sections and up to five subheadings. For example, the CPT code 15040 – Harvest of skin for tissue cultured skin autograft, 100 sq cm or less is organized under five subheadings.

These subheadings can be valuable when developing subsets or when conducting quality assurance checks. For example, when creating a cardiology physician specialty subset, the following subheadings can be used to identify an initial set of CPT codes for possible inclusion into a subset:

These two subheadings can be used to retrieve 922 CPT codes. A benefit of using an intensional approach as part of a subset definition is that the definition can be re-used in each release of CPT content to identify new CPT codes that have been added to these subheadings. The intensional approach can also be used to identify an initial set of CPT codes, which is then manually reviewed for confirmation of inclusion.

Cycle 2: Subset Enhancement

Cycle 2 is subset enhancement, which focuses on adding additional relevant CPT codes or Clinician Descriptors to the subset to improve the coverage of the subset. There are several ways enhancement can be done:

1. Related CPT Codes – An algorithmic approach whereby similar CPT codes that were not included in the subset are identified for review.
2. Expert Review – A CPT content expert can review CPT sections and subheadings to identify potentially relevant sections that should be included. This can be done if a subset was not developed using an extensional approach.
3. Subset Comparison – Comparing the subset developed with similar subsets developed by other organizations to determine the overlap and the gaps.

Related CPT® Codes

There are a number of methods to identify similar or related CPT codes and their associated Clinician Descriptors.

1. Add-on Codes – Identify add-ons that may be used with the primary CPT code, or identify primary CPT codes that must be used with add-ons.
2. Parent–Child Code Relationships – Identify the parent or child code for each CPT code.
3. Subheadings – Identify other CPT codes that are grouped into the same subheading.

Add-on Procedure Codes

CPT codes are designed as add-on procedure codes or primary procedure codes. As an add-on procedure code, a CPT code cannot be reported on its own but rather must be reported with a primary procedure code. For example, “33517 – Coronary artery bypass, using venous graft(s) and arterial graft(s); single vein graft (List separately in addition to code for primary procedure)” is an add-on procedure code. The guidelines state “(Use 33517 in conjunction with 33533-33536).” Therefore if 33517 is included in a subset, at least one of the following CPT codes should also be included in the subset.

Parent–Child Code Relationships

Within CPT® Link, CPT codes are defined as Parent Code (PC) or Child Code (CC). This is a method for grouping similar CPT codes together. For example, in the following table, 33030 – Pericardiectomy, subtotal or complete; without cardiopulmonary bypass is designated as the PC while 33031 – Pericardiectomy, subtotal or complete; with cardiopulmonary bypass is designated as the CC. Therefore if 33030 is contained in a subset, 33031 could possibly be relevant for inclusion.

Subheadings

As mentioned earlier, CPT codes are organized into sections and subheadings. These subheadings can be used to identify additional related CPT codes. The subheadings related to the section are broader while the headings related to the CPT code are more specific. The following table shows the section and subheadings for 15040 – Harvest of skin for tissue cultured skin autograft, 100 sq cm or less. The subheadings can be used to identify similar CPT codes.

Expert Review

If a subset was developed based on mapping legacy terms to the CPT® content, there is the possibility that the legacy terms are less granular than the CPT terms and that the mappings may not reveal all relevant CPT codes. As such, a CPT content expert can review and identify CPT content that may be relevant for inclusion in the subset. The potential CPT content should be brought to the clinician review group to determine if it is relevant.

Subset Comparison

If there exists another organization that has developed a subset with a similar use case, a comparison can be done to determine what the overlaps are as well as the gaps. Potential CPT content should be brought to the clinician review group to determine if it is indeed relevant.

Cycle 3: Subset Refinement

Cycle 3 is subset refinement, which focuses on removing irrelevant CPT codes and Clinician Descriptors to ensure the subset is fit for the intended purpose. When clinicians review CPT codes and Clinician Descriptors for inclusion into a subset, they may inadvertently include content that should not be included. This could be because they did not fully understand the CPT content, were fatigued as part of the review process and chose to include everything, or they accidently included content that they meant to exclude.

There are some areas in CPT content that may warrant special consideration for inclusion in a subset. One approach to identify potentially inappropriate content is to group the CPT content by CPT sections and subheadings. Sections and subheadings that have only a few CPT codes should be re-reviewed to ensure they are indeed relevant.

CPT sections and subheadings

Category II/III

CPT codes are divided into three categories:

Category I: Core Procedure CPT Codes – CPT codes for procedures that are consistent with contemporary medical practice and are widely performed.

Category II: Performance Measurement – CPT codes based on nationally established performance measures that are used for supplemental tracking of quality measures.

Category III: Emerging Technology – temporary CPT® codes for emerging technology, services, procedures, and service paradigms.

Depending on the purpose of a subset, Category II/III codes may not be appropriate for inclusion. There are two main ways to identify Category II and III codes:

1. Category II and III codes end with a “T” or “F” so a search for CPT® codes that end with “T” or “F” can be used to easily identify Category III codes.
2. Category II and III codes have CPT® Link internal concept identifiers of 1014507 and 1014405 respectively.

Evaluation and Management

Evaluation and Management (E/M) services encompass a broad range of services, spanning various locations (eg, office visit, hospital visit, nursing home), visit types (eg, new vs established patient, intensive care, neonatal intensive care), and patient acuity levels. Some examples include:

When refining a subset containing Evaluation and Management services, it is important to ensure that only those E/M services with the relevant locations and/or visit types are included in the subset.

Immunizations

CPT codes for immunization procedures can be included in individual physician specialty subsets or as a separate subset. The advantage of including immunization codes in individual physician specialty subsets is that all the necessary codes are contained within a single subset. The disadvantage of including immunization codes in individual physician specialty subsets is the maintenance process. If an immunization code that was included in multiple subsets is inactivated, those subsets need to be updated to exclude the specific immunization code.

Immunization codes are under the CPT section “Medicine.” Within the section, there are three subheadings:

When refining a subset containing immunization codes, it is important to consider the advantages and disadvantages of including them in a subset.

Unlisted Procedure Codes

Unlisted procedure codes may not be appropriate for a well-defined subset with specific use cases. Unlisted procedure codes are sometimes used as a “catch all” group when physicians/doctors are not able to locate the CPT code they want. The CPT code set includes approximately 150 codes for unlisted procedures. These CPT codes are scattered across different subheadings and there is no single subheading that includes all codes for unlisted procedures. A text search for “unlisted procedures” in the CPT Long Descriptor will easily identify all unlisted procedure codes in the CPT code set. Examples are listed below:

When refining a subset containing CPT codes for unlisted procedures, a decision has to be made as to whether CPT codes for unlisted procedures are appropriate for inclusion in a subset.

Process

The development of subsets involves the cooperation of health information management professionals and clinicians. Health information management professionals will manage the process of identifying potential CPT codes and Clinician Descriptors for inclusion into subsets as well as exclusion from subsets, while clinicians will confirm the choices.

When multiple individuals are involved in reviewing CPT codes and Clinician Descriptors to determine if they should be included in a subset, they may not always agree on what should be included. Naturally, CPT codes and Clinician Descriptors that all reviewers agree should be included should be added to the subset. With regard to disagreements, there are several approaches:

1. Include a CPT code or Clinician Descriptor if at least one reviewer deems it is relevant, or conversely, exclude a CPT code or Clinician Descriptor only if all reviewers deem it is irrelevant.
2. Re-review content together to determine if a consensus can be reached.
3. Create sub-specialty subsets. It may very well be that the disagreements are due to very specific sub-specialties. A more general specialty subset can be created, and sub-specialty subsets can also be created to cater to more specific practices.

The following figure provides a high-level overview of the interaction between health information management professionals and clinicians in the development of subsets.

Challenges

There are challenges that have been identified:

• Personnel: Involving clinicians in the review process can be a daunting task especially if there are thousands of CPT® codes and Clinician Descriptors to review. The clinicians must be made to understand the importance of their participation and how it will affect their practice in the future. Breaking down the number of terms a clinician has to review to a more manageable number (for example, a set of terms that can be reviewed within an hour) and honoraria may help to keep clinicians engaged. Having physician champions that can encourage other physicians/doctors as well as peer pressure can also aid the process.
• Tooling: Tooling is essential in developing subsets. Developing subsets via word processing documents or spreadsheets may not be the most efficient method especially on a larger scale. Web-based tooling should be available whereby clinicians do not need to download and install software, and user-friendly tooling can help manage the process. At the time of this writing, there are no known publicly available tools for developing CPT subsets.
• Process: If dozens of subsets and hundreds of physicians are involved, managing the process can be challenging. Having clear instructions, easy-to-use tooling, and identifying how this work impacts clinicians directly can help to mitigate this challenge. It is also important to have the appropriate tooling.

 

MODULE THREE: Subsets Distribution Format

Introduction

As the CPT® content becomes more widely adopted and the use of subsets becomes more widespread, it is important to define a standardized subsets distribution format so that organizations can share and compare content, as well as streamline implementation. A standardized format will also ensure that all the relevant information about a CPT code and Clinician Descriptor is included.

Intended Audiences

The intended audiences for this module include

• Health information management professionals – Health information management professionals will be responsible for using the tooling to generate the subsets output in the subsets distribution format.
• Vendors – Vendors will be incorporating the subsets into their systems and will therefore need to know how the subsets are structured.

Learning Objectives

After reviewing the content in this module, the reader is expected to be able to:

• Describe the need for having a standard subsets distribution format.
• Describe the subsets file structures, formats, names, and types of releases.

Subsets Distribution Format 

The content of the files in the distribution format will depend on whether a CPT code subset or a Clinician Descriptor subset was created. This module focuses on Clinician Descriptor subsets as that is the more complex or comprehensive of the two.

Personnel

• Health information management professionals – Health information management professionals will be responsible for using the tooling to generate the subsets output in the subsets distribution format.

Tooling

Tooling plays a critical role in the development of subsets and also plays a key role in exporting the subsets in a machine-processable format that can be used in electronic systems.

Tooling requirements include:

• Tooling must be able to generate the required files in the required file format and with the required file names.

Approach

File structures

A minimum of four files are required as part of the subsets distribution format.

1. Subsets
2. Subset Members
3. Subset Members History
4. Subset Members Replacement

The file structures include the minimum CPT® content that is needed to contain the subset content. While the data types for the CPT content (ie, CPT code, Long Descriptor, Clinician Descriptor Id, Clinician Descriptor) should not be altered, other fields may be changed. Other files such as modifiers, guidelines, and sections or subheadings are outside the scope of this module.

Each file has a single data field, EffectiveDate. This indicates the date when the row in a table was added. The EffectiveDate and Active fields determine whether a row is active or inactive in a specific release. It is also possible to include two dates, StartDate and EndDate, in place of EffectiveDate. The advantages and disadvantages of each approach are summarized in the following table:

Subsets

The Subsets file contains the name of the CPT subsets that have been published. The columns, data type, and description of the columns are shown in the following table.

Subset Members

The CPT Subset Members file contains the list of CPT codes and Clinician Descriptors that are included in a subset. The columns, data type, and description of the columns are shown in the following table.

Although CPT Category I codes are numeric, are five characters in length, and are the only category of codes used in the subset, the Anesthesia procedure codes start with leading zeros. As such, the data type for the Code field is specified as char(5) instead of integer. There is no specified upper limit to the length of the Descriptor or ClinicianDescriptor columns. Practically speaking, the Descriptor is not shown to clinicians at the point of care. The ClinicianDescriptorId and ClinicianDescriptor columns are of particular interest because the ClinicianDescriptor contains the descriptions that will be shown to physicians while the ClinicianDescriptorId will be recorded into an electronic health record system.

Other optional fields that may be included include:

The ConceptId field may be included to retrieve other content available in CPT® Link. If necessary, additional fields such as SectionId and AddOn can also be included in the subsets members file to indicate which of the six sections a CPT code belongs to and whether a CPT code is an add-on code. The AddOn field can be a Boolean field whereby “0” indicates the CPT code is not an add-on code while “1” indicates the CPT code is an add-on code. The SectionId can contain one of the sections:

1. 1013625 – Evaluation and Management Services
2. 1002796 – Anesthesia
3. 1003143 – Surgery
4. 1010251 – Radiology Procedures
5. 1011136 – Pathology and Laboratory Procedures
6. 1012569 – Medicine Services and Procedures

The primary purpose of including the SectionId is to easily identify modifiers that may be used in conjunction with a CPT code.

The following table shows examples of rows in the CPT® Subset Members file without the dates and active fields.

Subset Members History

The CPT Subset Members History file provides a reason why a CPT Clinician Descriptor has been activated or inactivated in a subset.

The columns, data type, and description of the columns are shown in the following table.

The Reason field could also be added to the CPT Subset Members table if required to consolidate the number of tables.

The following table shows examples of rows in the CPT Subset Members History file. The ClinicianDescriptor and ReasonDescriptor columns are added for clarity.

Subset Members Replacement

The CPT® Subset Members Replacement file records the replacement CPT code for each inactivated CPT code. While the subset members are Clinician Descriptor–based, the replacements are CPT code–based.

The columns, data type, and description of the columns are shown in the following table.

Each CPT code that is inactivated may be replaced with an active CPT code. For example, the CPT codes 69400 – Eustachian tube inflation, transnasal; with catheterization and 69405 – Eustachian tube catheterization, transtympanic were included as part of the subset development process but were later inactivated and replaced by 69799 – Unlisted procedure, middle ear. The following table shows examples of rows in the Subset Members Replacement CPT file. The Descriptor and ReplacementDescriptor columns are added for clarity.

File formats

CPTcontent is distributed via a variety of file formats in CPT® Link. As such, CPT subsets should match the formats. They include:

1. Pipe-delimited text files
2. Tab-delimited text files
3. eXtensible Markup Language (XML) files

The difference between the pipe-delimited text files and the tab-delimited text files are the delimiters. The pipe character refers to “|” without the quotes.

File names

File names are important in allowing uses of the subsets to easily identify the file structure and when it was released.

Examples of CPT files names in CPT® Link include:

1. Property_DTK_pipe.txt
2. Property_DTK_tab.txt
3. Dtk.xml

For the pipe and tab files, they are included in the file names. The release dates, however, are not included. The ideal file names should include the date when the file is published for distribution.

1. Subsets_pipe_YYYYMMDD.txt
2. Subsets_tab_YYYYMMDD.txt
3. SubsetMembers_pipe_YYYYMMDD.txt
4. SubsetMembers_tab_YYYYMMDD.txt
5. SubsetMembersHistory_pipe_YYYYMMDD.txt
6. SubsetMembersHistory_tab_YYYYMMDD.txt
7. SubsetMembersReplacement_pipe_YYYYMMDD.txt
8. SubsetMembersReplacement_tab_YYYYMMDD.txt

As xml files can contain multiple contents, they can just be included in a single file Subsets_YYYYMMDD.xml.

File release types

Subsets should be released in at least three release types. The following are based on the SNOMED CT® release types.[1]

1. Full – The full history of the subsets is included in the release.
2. Snapshot – Only a specific release of the subsets is included. The full history of changes is unavailable in this release.
3. Delta – Only the changes between the current release and the immediate previous release are included. This release enables users to incrementally keep their subsets up to date.

Process

The only step is for a health information management professional to use the tooling to export the subsets in the subsets distribution format.

 

MODULE FOUR:  Subsets Quality Assurance and Maintenance

Introduction

The CPT content is used by organizations for many purposes including, but not limited to, clinical documentation, reimbursement, patient case queries, resources planning, and budgeting. Subsets are the primary source of CPT content that clinicians use to report the procedures and services they provide; therefore, it is imperative that the subsets are of high quality. To ensure subsets are of high quality, quality assurance checks and maintenance must be routinely conducted.

Typically, a major update to CPT content is released every year with two additional minor updates throughout the year. With each update, CPT codes, Long Descriptors, and Clinician Descriptors may be added, changed, or deleted. As such, it is important to understand how these changes affect CPT subsets and the maintenance process that needs to be carried out to ensure CPT subsets are up to date.

Subsets quality assurance should be conducted by the creator of the subsets. Vendors who incorporate the subsets into their systems should not need to conduct quality assurance checks.

Intended Audiences

The intended audiences for this module include

• Clinicians – Clinicians will participate in the subsets quality assurance check and subsets maintenance process by reviewing CPT® codes and Clinician Descriptors that have changed and/or been deleted. They will also review new CPT codes and Clinician Descriptors added to a new release of CPT content. This module will familiarize clinicians with the types of changes in CPT content and how these will affect their subsets.
• Health information management professionals – Health information management professionals will be responsible for generating the list of changes to CPT content that affects a subset. Generating these changes should be done via a tool. This module will familiarize health information management professionals with the types of changes in CPT content that they will bring to clinicians for review.
• Executives – Subsets are not static; that is, changes in CPT content will affect subsets in almost every CPT content release. Executives need to be aware of the need to routinely update subsets and therefore allocate sufficient resources to maintain subsets. This module will familiarize executives with the types of changes CPT content undergoes and how these will affect clinicians and health information management professionals.

Learning Objectives

After reviewing the content in this module, the reader is expected to be able to:

• Describe the different quality assurance checks and why they are important.
• Explain the process of conducting quality assurance checks on subsets.
• Describe the types of changes CPT content undergoes and how that will affect subsets.
• Describe the process for maintaining CPT subsets.
• Describe how CPT® Link can be used to maintain subsets.
• Summarize the tooling requirements to support subset maintenance.
• Apply subset maintenance checks to CPT subsets.

Personnel

1. Health information management professionals – Health information management professionals will be the individuals who initiate the quality assurance checks and subset maintenance process when an update of CPT® content is released. They will, through the available tooling, identify changes that affect the subsets and will work with clinicians to update the subsets.
2. Clinicians – Where applicable, clinicians will be involved to review changes in CPT content that affect their subsets.

Tooling

Subsets can contain several thousand CPT codes and Clinician Descriptors. As such, it is not feasible to manually conduct subsets quality assurance checks. The tooling used to develop the subsets should also be able to conduct the quality assurance checks.

Tooling requirements include:

1. Tooling must be capable of performing quality assurance checks and subsets maintenance using a specified CPT content release.
2. Tooling must be able to generate reports on changes including:
   1. CPT codes that have been deleted
   2. Replacement CPT codes for deleted CPT codes
   3. Clinician Descriptors that have been deleted
   4. Replacement Clinician Descriptors for changed Clinician Descriptors
3. Tooling must allow clinicians to select replacement CPT codes and Clinician Descriptors.
4. Tooling must be able to export the updated subsets in the desired format.

Approach

With each CPT content release, new CPT codes are added while existing CPT codes may be changed, updated, or deleted. As an example, the following table shows the number of CPT codes added, changed, and deleted  in the five annual CPT content releases between 2015 and 2019.

The AMA only recently began keeping a comprehensive log of CPT Clinician Descriptors and the log is only applicable between two releases. Therefore, the summary of changes listed in the following table only shows the updates between the 2018 and 2019 CPT content releases.

All these changes point to the need of maintaining CPT® subsets to ensure the list of CPT codes and Clinician Descriptors is current.

Quality Assurance

1. Each add-on code must have at least one primary CPT code
2. CPT codes must be from the appropriate category
3. CPT codes must be from the appropriate section and subheading

Maintenance (New Content)

4. New CPT code
5. New Clinician Descriptor

Maintenance (Existing Content)

6. CPT code deleted
7. Clinician Descriptor deleted
8. Change in Long Descriptor
9. Change in Clinician Descriptor
10. CPT code no longer required
11. Clinician Descriptor no longer required

The following figure provides an overview of the subsets maintenance checks for the six types of changes.

Each add-on code must have at least one primary CPT code

CPT codes are designated as add-on codes if they need to be reported in conjunction with a primary code. For example, the add-on CPT code 22103 – Partial excision of posterior vertebral component (eg, spinous process, lamina or facet) for intrinsic bony lesion, single vertebral segment; each additional segment (List separately in addition to code for primary procedure) has the following guideline:

(Use 22103 in conjunction with 22100, 22101, 22102)

Therefore, if CPT code 22103 is included in a subset, at least one of the three primary CPT codes must also be included in the subset:

1. 22100 – Partial excision of posterior vertebral component (eg, spinous process, lamina or facet) for intrinsic bony lesion, single vertebral segment; cervical
2. 22101 – Partial excision of posterior vertebral component (eg, spinous process, lamina or facet) for intrinsic bony lesion, single vertebral segment; thoracic
3. 22102 – Partial excision of posterior vertebral component (eg, spinous process, lamina or facet) for intrinsic bony lesion, single vertebral segment; lumbar

Each add-on code should contain at least one primary code in each subset. Add-on codes that do not have any primary CPT codes must be removed, or one or more primary CPT codes must be added to the subset.

Identifying the primary code for an add-on code can be done using the Report With file.

Report With File

The Report With file is contained in the folder CPT® Link\edits\ReportWith.txt. The Report With file contains the code and descriptor of the add-on code in the first two columns and code and descriptor of the primary or main code in the next two columns. Returning to the previous example of CPT code 22103, the following table shows how the add-on and primary codes are stored. Therefore, in a quality assurance check, if CPT code 22103 is included in a subset, a check can be done to determine if CPT codes 22100, 22101, and 22102 are also included in a subset. If none of them is included, a suggestion must be made to either include at least one of them or exclude the add-on code.

 

CPT codes must be from the appropriate category

CPT codes are divided into categories:

Category I is the major terminology. It contains a description along with its five-character code for each procedure. Category I codes are divided into six sections: (a) Evaluation and Management, (b) Anesthesia, (c) Surgery, (d) Radiology, (e) Pathology and Laboratory, and (f) Medicine.

Category II is used for performance measurement. It was created to support data collection about the quality of care rendered by coding certain services and test results that support nationally established performance measures and that have an evidence base as contributing to quality patient care. Category II codes are alphanumeric.

Category III is for emerging technologies, services, and procedures. They are considered “temporary” and they may or may not eventually be moved to Category I. Category III codes are alphanumeric.

Depending on the purpose of the subset, only CPT codes for a specified category may be included. CPT codes from other categories must be excluded, if that is the definition of the subset.

CPT codes must be from the appropriate section and subheading

In addition to ensuring CPT codes are from the appropriate category, an additional quality assurance check is done to ensure CPT codes are from the appropriate section or subheading. For example, most CPT codes for a cardiology physician specialty subset should come from the following subheadings:

If a CPT code is not from one of those subheadings, a manual check should be done to evaluate if the CPT code should indeed be included in the subset.

New CPT code

With each CPT content release, new CPT codes are added, some of which may be relevant for existing subsets. As an example, the following table shows the numbers of new CPT codes for certain past CPT content releases.

These new CPT codes should be reviewed to determine if they should be included in a subset. Using the methods defined in Cycle 3: Subset Enhancement, these new CPT codes can be queried to determine if they are similar or related to existing CPT codes in a subset. If they are relevant, the Clinician Descriptors should also be reviewed to determine if they should be included.

New clinician descriptor

New Clinician Descriptors are sometimes added to existing CPT® codes as they are new descriptors that improve the collective completeness of Clinician Descriptors for a CPT code or they are added to correct erroneous Clinician Descriptors. Queries should be conducted to identify new Clinician Descriptors for existing CPT codes in a subset to ensure all relevant Clinician Descriptors are included.

For example, the CPT code 99091 – Collection and interpretation of physiologic data (eg, ECG, blood pressure, glucose monitoring) digitally stored and/or transmitted by the patient and/or caregiver to the physician/doctor or other qualified health care professional, qualified by education, training, licensure/regulation (when applicable) requiring a minimum of 30 minutes of time included a single Clinician Descriptor in each of the five annual releases of CPT content prior to the 2019 release.

• 10017347 – Collection and interpretation of physiologic data digitally stored and transmitted

In the 2019 CPT release, the single Clinician Descriptor was deleted and five new Clinician Descriptors were added:

1. 10030189 – Collection and interpretation of digital blood glucose monitoring data by qualified healthcare professional requiring a minimum of 30 minutes of time, per 30 days
2. 10030190 – Collection and interpretation of digital blood pressure monitoring data by qualified healthcare professional requiring a minimum of 30 minutes of time, per 30 days
3. 10030191 – Collection and interpretation of digital electrocardiograph data by qualified healthcare professional requiring a minimum of 30 minutes of time, per 30 days
4. 10030192 – Collection and interpretation of digital electrocardiograph monitoring data by qualified healthcare professional requiring a minimum of 30 minutes of time, per 30 days
5. 10030193 – Collection and interpretation of digital physiologic data by qualified healthcare professional requiring a minimum of 30 minutes of time, per 30 days

If CPT code 99091 is included in a subset, these five Clinician Descriptors should be reviewed for possible inclusion.

CPT code deleted

With each release of the CPT content, there are CPT codes that are deleted (inactivated). There are several reasons a CPT code may be deleted:

1. There is a new CPT code that better represents the procedure done than the existing CPT code.
2. The CPT code was a Category III code that is now being migrated to a Category I code.
3. The procedure is no longer being done and therefore the CPT code is no longer required.

To ensure a subset contains only active CPT codes, each CPT code in a subset must be checked to ensure it is still active in the specified CPT release. Deleted CPT codes must be removed, and where applicable, replacement CPT codes should be added to the subset.

When a CPT code is deleted, it must be removed from the subset. CPT content includes a historical reference table to indicate what the replacement CPT code should be. If the replacement CPT codes are appropriate, the Clinician Descriptors, where applicable, should be included.

Identifying CPT codes that have been deleted can be done in two ways:

1. Checking each CPT code in a subset against the set of CPT codes in a specific CPT release. If the specific CPT code exists in the set, the CPT code is active.
2. Checking each CPT code in a subset against the set of deleted CPT codes. If the specific CPT code exists in the set, the CPT code has been deleted.

Within CPT® Link, there are several files that contain a list of deleted CPT codes and the replacement CPT codes. The following are the tab-delimited text files:

1. CPT® Link\history\Deleted_DTK_pipe.txt or
   CPT® Link\history\Deleted_DTK_tab.txt
2. CPT® Link\history\Deleted_DTK_pipe.txt or
   CPT® Link\history\History_DTK_tab.txt
3. CPT® Link\history\Deleted_DTK_pipe.txt or
   CPT® Link\history\HistoryReference_DTK_tab.txt

Deleted file

The Deleted File contains a log of CPT content that has been deleted. It should be noted that the deleted file lists other deleted CPT content such as CPT headings in addition to CPT codes.

History file

The History File contains a log of CPT content that has been added, changed, or deleted. The Current Value column in the following table has been omitted since it is blank when Change Type contains a value of DELETED.

History reference file

The History Reference File contains a list of replacement CPT codes for deleted CPT codes and does not contain descriptors. Also, instead of using CPT codes, CPT® Link’s internal concept identifiers are used instead. Concept Id 1 refers to the concept identifier of the CPT code that has been deleted.

The Relationship Type Id field can contain two values:

1. 400 – Replaced_by
2. 401 – Refer_to

According to the CPT® Link Read Me file, the different relationship types relate to the type of guideline or instruction (“see” vs “use”) that is provided for delete CPT codes. “Replaced by” is definitive in that the replacement CPT code identified is appropriate for all uses while the “refer to” relationship requires additional considerations as to whether the suggested replacement CPT code is appropriate.

Clinician descriptor deleted

With each release of the CPT content, Clinician Descriptors are deleted (inactivated). There are several reasons a Clinician Descriptor may be deleted:

1. The CPT code is deleted so all associated Clinician Descriptors are deleted.
2. The Clinician Descriptor contains an error and needs to be corrected. In this case, rather than changing the Clinician Descriptor, a new Clinician Descriptor identifier is issued for the fixed Clinician Descriptor.

The numbers of Clinician Descriptors deleted over three annual CPT® releases are shown in the following table.

To ensure a subset contains only active Clinician Descriptors, each Clinician Descriptor in a subset must be checked to ensure it is still active in the specified CPT release. Deleted Clinician Descriptors must be removed, and where applicable, replacement Clinician Descriptors should be added to the subset.

Change in long descriptor

This maintenance process focuses on whether a change has been made to a Long Descriptor between two CPT content releases. Long Descriptors occasionally change over time, as shown in the following table:

Examples of changes in the Long Descriptor include:

 

Annual changes in the Long Descriptors are identified in the files:

• CPT® Link\changes annual\Changes_20170901_20180901.txt
• CPT® Link\changes annual\Changes_20170901_20180901.xml
• CPT® Link\changes annual\Changes_20170901_20180901.xlsx

While incremental changes are identified in the files:

• CPT® Link\changes incremental\Changes_20170901_20180901.txt
• CPT® Link\changes incremental\Changes_20170901_20180901.xml
• CPT® Link\changes incremental\Changes_20170901_20180901.xlsx

Change in clinician descriptor

A review of the historical Clinician Descriptors indicates that the Clinician Descriptor Id and Clinician Descriptor are immutable. That is, the text in a Clinician Descriptor is never changed. If a change is necessary, for example, to fix a spelling mistake, a new Clinician Descriptor Id is issued and the old Clinician Descriptor is deleted (inactivated).

In the following example, the words “weight of” were incorrectly spelled as “weightof” in 2015-01-01. This was corrected in 2016-01-01, but with a new Clinician Descriptor Id.

The difference between a Clinician Descriptor being completely deleted and a “change” in a Clinician Descriptor is that a historical link can be made between the two so that clinicians can identify the replacement Clinician Descriptor.

Process

1. For each subset, a health information management professional will use the tooling to generate a list of changes to each subset.
2. If there are significant changes, the health information management professional may choose to break down the changes into smaller sets for clinicians to review.
3. The health information management professional will assign each subset to clinicians for review.
4. Clinicians will use the tooling to review changes to each subset and confirm the suggested changes.

Challenges

1. Tooling – Manually checking each CPT® code or Clinician Descriptor to determine if a change has been made is a time-intensive exercise that is prone to introducing mistakes. As such, tools that automatically check subsets against different releases of the CPT content should be used. There are, however, no known publicly available tools to manage and update subsets. Nevertheless, it is possible to conduct these quality assurance checks if the subsets are contained in a database along with CPT® Link. A few structured query language (SQL) statements can be used to run these quality assurance checks.
2. Process – Subsets maintenance requires a terminology team to generate the list of changes, a team of clinicians to review updates to the subset, and a process of distributing the updates to clinicians, vendors, and claims adjudicators.
3. CPT® Link – CPT® Link includes a historical log of changes to Clinician Descriptors. However, there are still several challenges:
   • The full change log of Clinician Descriptors is not available.
   • The change log is only available between the current and previous release.
   • The change log does not include Clinician Descriptor identifiers. Therefore, the change log table must be cross referenced with the Clinician Descriptors table to identify the associated Clinician Descriptor identifiers.
   • The change type recorded in the log is not always consistent. For example, the following table shows changes to two CPT® codes, 36568 and 36569. In the case of 36568, two Clinician Descriptors were deleted and one new Clinician Descriptor was added.  However, in the case of 36569, one Clinician Descriptor was changed and another was deleted.

 

MODULE FIVE:  CPT Subsets Documentation

Introduction

Subsets only contain CPT codes and Clinician Descriptors that are relevant for a specific use case. However, only stating the use case of a subset and the number of CPT codes and Clinician Descriptors that it contains does not adequately describe what is contained within a subset. This module describes an approach on how the content of CPT subsets can be described and summarized in a way that makes sense to clinicians and health information management professionals.

Intended Audiences

The intended audiences for this module include

• Clinicians – As clinicians are the primary users of subsets, they should be aware of what their subsets contain. This module will help clinicians consume the subsets in a way that makes sense to them.
• Health information management professionals – Health information management professionals will be instrumental in producing the summaries of the subsets and therefore should be aware of the content that clinicians will be receiving.
• Vendors – Understanding how clinicians and health information management professionals consume subsets may help in developing more user-friendly systems.

Learning Objectives

After reviewing the content in this module, the reader is expected to be able to:

• Describe the approaches to summarize the contents of a subset in a succinct manner that is understandable to clinicians.

CPT Subsets Documentation 

Personnel

Health information management professionals will be largely responsible for developing subset summaries via the appropriate tooling.

Tooling

Manually generating summaries of subsets can be a time-consuming task. Where possible, tooling should be used to generate the summaries.

Tooling requirements include:

1. Tooling must be able to generate specified summaries from a subset already imported into the tool.
2. Tooling must be able to take a CPT content release input as a parameter.

Approach

CPT subsets documentation should include the following:

1. Individual or team in charge of maintaining the subset and contact information
2. Intended purpose of the subset
3. The date the subset was released
4. Which CPT® content release was used to develop the subset
5. Who should use the subset
6. A description of how the CPT codes and Clinician Descriptors were selected for inclusion
7. Who was involved with developing the subset and reasons for their involvement
8. The process followed to develop the subset
9. Subset development challenges and how they were addressed
10. Subset maintenance process

In addition, if there are functional requirements for subsets implementation, they should also be referenced.

In addition, the actual contents of the subsets should be described; that is, what types of CPT codes and Clinician Descriptors have been included in the subset. There are five main ways of describing CPT subsets:

1. CPT Code Set Sections
2. CPT Subheadings
3. Add-on Codes
4. Number of Clinician Descriptors per CPT Code
5. Length of Clinician Descriptors

CPT code set sections

Category I CPT codes are organized into six sections. A summary table that lists the numbers of CPT codes for each CPT section provides a high-level overview of a CPT subset and can also serve as a quality assurance check. For example, if an anesthesiologist reviews the summary table and notices that all the CPT codes in the anesthesia subset are from the Evaluation and Management and Anesthesia sections, the anesthesiologist can have a higher level of confidence that the subset contains only those CPT codes that are relevant.

CPT subheadings

While the CPT sections provide a very high-level overview of the content contained within a subset, the overview still does not provide adequate detail about what is contained within the subsets. Within the CPT code set, each CPT section is further divided into subheadings, which are also further divided into additional subheadings to the fifth level. The following table summarizes the number of CPT codes by the first heading in the Surgery section as an example of what may be included in a subset documentation.

Add-on codes

Within the CPT® code set, some CPT codes are designated as “add-on codes.” These add-on CPT codes are intended to be used in conjunction with other main or primary CPT codes.

A summary table can be used to show the number of primary codes and non-add-on codes contained in a subset. This may help to inform clinicians that there will be situations in which they will have to select more than one CPT code to accurately report a procedure done or service provided.

Number of clinician descriptors per CPT code

The CPT Long Descriptors are often lengthy, technical, include multiple procedures, and sometimes contain examples. As such, these descriptors are not conducive for use by physicians/doctors. Each CPT code includes one or more Clinician Descriptors. These descriptions are clinician friendly terms that were designed to be used by physicians. Clinician Descriptors sometimes are more detailed or specific than the CPT Long Descriptors.

For example, the CPT code 64716 – Neuroplasty and/or transposition; cranial nerve (specify) includes three Clinician Descriptors. These three Clinician Descriptors allow physicians to specify exactly whether it is a neuroplasty, a transposition, or a neuroplasty and transposition of abducens nerve.

1. 10027729 – Neuroplasty and transposition of abducens nerve
2. 10027741 – Neuroplasty of abducens nerve
3. 10027753 – Transposition of abducens nerve

A summary table, such as the example below, can be used to show the number of Clinician Descriptors per CPT code.

 

Length of clinician descriptors

The length of Clinician Descriptors may be a reflection of the complexity of the procedure or service. Knowing the length of the Clinician Descriptors can also help electronic medical records and billing vendors develop their systems. In the subset documentation, a summary table that shows the lengths of Clinician Descriptors should be included. The following table is an example of the layout of a summary table using all Clinician Descriptors available in CPT content.

Process

If the tooling has been configured to the specified requirements, the process of generating the summaries of subsets is straightforward:

1. For each subset, a health information management professional will input the required subset and CPT content release.
2. The tooling will generate the summaries.
3. The health information management professional will package the summaries in the specified template.

Challenges

If tooling is available to generate the CPT® subsets documentation, there are no foreseeable challenges.

 

 

MODULE SIX: Subsets Functional Requirements

Introduction

When moving from adoption to technical implementation, it is important that functional requirements are explicitly and unambiguously defined to ensure the subsets are implemented correctly and consistently across different electronic systems/products, regardless of the vendor of the electronic systems/products. While the user interface for each vendor’s system/product will look different, each vendor’s system/product must still fulfill the functional requirements.

This module focuses on describing the minimum functional requirements and can be viewed as the starting point for organizations planning on implementing CPT® subsets. If additional functional requirements need to be specified, health information management professionals should work with clinicians and vendors to identify additional needs. Tooling is not required to develop the functional requirements.

Intended Audiences

The intended audiences for this module include

• Clinicians – Clinicians will likely be using electronic systems/products that have been modified to accommodate the CPT content, the requirements of which are based on these functional requirements. This module helps to inform clinicians of the changes that will be made and can help to ensure a smooth transition to using CPT content.
• Vendors – Vendors will be making the changes to their electronic systems/products. This module will familiarize vendors with the functional requirements needed to support CPT content implementation. Technical analysts and programmers that are in-house are considered vendors for the purpose of this module.

Learning Objectives

After reviewing the content in this module, the reader is expected to be able to:

• Describe the technical implementation requirements needed to correctly and consistently implement the CPT subsets.

Subsets Functional Requirements

Approach

The functional requirements to implement CPT subsets can be grouped into six categories:

1. Subsets Management – Requirements for how CPT subsets are managed.
2. Data Capture – Requirements for searching and entering CPT content into patient records.
3. Data Storage – Requirements for storing CPT content identifiers in patient records.
4. Data Display – Requirements for displaying CPT terms from patient records.
5. Data Retrieval – Requirements for retrieving patient records coded using CPT content.
6. Data Exchange – Requirements for exchanging CPT content between clinical systems.

Subsets Management can be viewed from a system’s configuration or settings perspective while Data Capture, Data Display, and Data Retrieval can be viewed from a system’s front-end interface. Data Storage and Data Exchange focus on the back-end database and interoperability functionality.

The language used in these functional requirements is in line with the standard key words, shown in the following figure, used in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2119.[1]

1. MUST – This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.

2. MUST NOT – This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification.

3. SHOULD – This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT – This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

5. MAY – This word, or the adjective “OPTIONAL”, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.  An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).

As these functional requirements focus on required and recommended requirements, optional requirements are omitted.

Subsets management

Subsets Management can be viewed from a system’s configuration or settings perspective. When setting up an electronic patient records system, there should be a configuration or settings page or section to allow a user to manage the subsets. The Subsets Management functional requirements are:

1. SM1 – Systems MUST have functions to import subsets and supporting files. Systems MUST have functions to import the subsets in a specified format whenever they are updated. This includes the subsets and other supporting CPT® content files.
2. SM2 – Systems MUST allow users to view information about a subset. Users MUST be allowed to view information about a subset including the subset date of publication, CPT content release, and the total number of active and inactive CPT codes and Clinician Descriptors contained in the subset. Subsets Management interfaces MUST have similar searching and browsing functionality such as those described in DC3 and DC4 to allow users to review the terms in the subsets. Users MUST also be allowed to view a list of terms that were added and inactivated since the previous update.
3. SM3 – Systems MUST allow users to select subsets to be used in data capture. Systems MUST have a setting that allows users to choose the subsets they want to use in health services for the purpose of clinical reporting. Users MUST be allowed to select multiple subsets and MUST only be allowed to select active subsets.
4. SM4 – Systems MUST NOT allow users to modify the terms in the subsets. Users MUST NOT be allowed to edit or delete any of the contents of the subsets. This means users MUST NOT be allowed to create any new local terms or synonyms.

Data capture

Data Capture can be viewed from a system’s front end, where, for example, a clinician is documenting a patient encounter. The functional requirements focus largely on searching, browsing, and validating data capture. Most of the functional requirements are based on best practice guidelines. The Data Capture requirements are:

1. DC1 – Systems MUST only allow active terms to be used. Users MUST only be allowed to search and browse active terms, which are to be used for capturing health services for clinical reporting.
2. DC2 – Systems MUST only allow searching by specific subsets. Users MUST be allowed to search for terms in specific subsets as specified in requirement SM3.
3. DC3 – Systems MUST allow users to search terms and codes. When using the CPT® subsets, users MUST be able to search using the CPT codes and Clinician Descriptors. The searches may be activated either via autocomplete functionality or by clicking (or entering) to search. The recommended search algorithms should include a combination of (a) exact match, (b) phrase match, (c) all match, (d) starts with match, (e) wildcard match, and (f) partial match. The recommended sorting algorithm includes length of terms in ascending order followed by alphabetical order. Proprietary search algorithms may also be used as long as the relevant search results may be retrieved.
4. DC4 – Systems MUST allow users to browse terms in a list and hierarchical structure. Users MUST be allowed to browse the terms in a subset in both a list form as well as a hierarchical structure. In a CPT subset, the list form should be sorted by CPT code and MUST display the CPT code, descriptor, and Clinician Descriptor. In a CPT subset, codes are organized under a maximum of five subheading levels plus the section.
5. DC5 – Systems MUST support the use of modifiers. Systems MUST be able to display optional modifiers that can be used with a CPT code. Systems MUST also allow for the selection of up to six modifiers for a CPT code.
6. DC6 – Systems MUST validate CPT codes (and modifiers, where applicable) against the guidelines. Systems MUST have functions in place to validate CPT codes (and modifiers, where applicable) before they are submitted in the service encounter record to the claims administrator. Systems MUST also display reasons why a CPT code (and modifiers, where applicable) is rejected.
7. DC7 – Systems MUST display an alert when an add-on CPT code is selected without a primary CPT code. In most cases, when an add-on code is selected without a primary code, an alert will be shown during Data Capture. There are, however, some add-on codes that do not have any associated guidelines. In these cases, an alert needs to be shown to users. If an add-on CPT® code does not have an associated guideline, systems MUST display the following alert to users: “(List separately in addition to code for primary procedure)”.
8. DC8 – Systems MUST NOT truncate or alter terms contained in the search results. Systems MUST ensure that the terms retrieved in search results are displayed in full, without any truncation. Systems MUST also ensure that the terms are displayed as shown in the source files without any alterations (eg, no change in capital casing). Clinician Descriptors can be as long as 482 characters.
9. DC9 – Systems SHOULD display additional information for terms. Additional information about a CPT Clinician Descriptor SHOULD be displayed in the form of tooltips, dialog boxes, or popups. For CPT® content, this SHOULD include the CPT code, descriptor, guidelines (rules), and relative value units.
10. DC10 – Systems SHOULD allow autocomplete searches. Systems SHOULD allow subsets to be searched using autocomplete. That is, search results SHOULD start to be retrieved once a user types a few characters of a search term.
11. DC11 – Systems SHOULD indicate when search activity is occurring, when there are no results, or when a search has failed. Systems SHOULD have a search activity indicator to inform a user a search is in progress, SHOULD include a message when no results were found, and SHOULD include an error message if a search has failed.
12. DC12 – Systems SHOULD highlight search tokens. When search results are shown, search tokens SHOULD be highlighted. The highlighting can be in the form of bolded text or different colors. The highlighting of search tokens SHOULD be implemented in both autocomplete searches and click (or enter) searches.

Data storage

Data Storage can be viewed from a system’s back end where the data that have been captured are stored. The Data Storage requirements ensure that whatever is entered at Data Capture is adequately stored. There is only one requirement for Data Storage:

1. DS1 – Systems MUST store CPT Clinician Descriptor identifiers in individual patient records. CPT Clinician Descriptor identifiers are 8 digits. Systems MUST store these identifiers in individual patient records or store an internal identifier that is linked directly to these identifiers. Storing only the CPT concept identifier or CPT code is insufficient. Storing the CPT code in patient records in addition to the SNOMED CT description identifier and CPT Clinician Descriptor identifier can help improve the performance of some types of data retrieval.

As clinicians are expected to use Clinician Descriptors, it is the Clinician Descriptor identifier that must be recorded in a patient record. The CPT code and Clinician Descriptor may also be stored, but the CPT code will be redundant as a Clinician Descriptor is immutable; that is, a Clinician Descriptor is always linked to a CPT code and this can never change.

Data display

Data Display can be viewed from a system’s front end, where, for example, a clinician is viewing a patient record that was previously populated with CPT content, or a patient case query screen where a clinician can search for patients who have received a service. The Data Capture requirements are important in ensuring whatever descriptor is used in Data Capture is the same one used when displaying. The Data Display requirements are:

1. DD1 – Systems MUST display the same term used in data capture when displaying the terms in individual patient records. Requirement DS1 facilitates the display of the appropriate description if the term is not saved in an individual patient record in addition to the CPT Clinician Descriptor identifier.
2. DD2 – Systems MUST display the Long Descriptor for aggregated patient records. The CPT descriptor (also referred to as the Long Descriptor) MUST be used as the display term when aggregating patient records to a CPT code. Since Clinician Descriptors are not synonyms and do not have a preferred term, the CPT descriptor is the only viable option.

Data retrieval

Data Retrieval can be viewed from both a system’s front end and back end. The front end is where a clinician will enter search criteria while the back end is where the query is computed. Data Retrieval requirements are important because clinical documentation is just one of the uses of CPT content. CPT data can be used for a myriad of purposes so it is important that the data can be retrieved. In the context of an electronic patient record system, Data Retrieval ensures clinicians can identify patients who have received a specified health service or had a procedure done. The Data Retrieval requirements are:

1. DR1 – Systems MUST support retrieval of patient records using CPT identifiers. Systems MUST have search capabilities for retrieving patient records using CPT code and Clinician Descriptor identifiers levels. Data Retrieval interfaces MUST have similar searching and browsing functionality such as those described in DC3 and DC4 to identify the appropriate CPT terms.
2. DR2 – Systems MUST support retrieval of patient records that contain inactivated terms. Systems MUST have search capabilities for aggregating patient records using CPT headings (ie, CPT sections, subheadings, and heading summary levels). Data Retrieval interfaces MUST have similar searching and browsing functionality to those described in DC3 and DC4 to identify the appropriate CPT terms.
3. DR3 – Systems SHOULD support retrieval of patient records using CPT headings. Systems MUST be able to include terms that are now inactivated in subsets but have been used in patient records via the historical relationships provided. When CPT codes are inactivated, there is a historical mechanism that links inactivated concepts and codes with replacement active concepts and codes.

Data exchange

Data Exchange focuses on interoperability whereby clinical systems exchange information with other clinical systems, especially across vendor products and platforms. The information specified that must be exchanged will help to ensure semantic interoperability; that is, not only is the information exchanged between a source system and a target (destination) system, but the target system is able to understand or make use of the information exchanged. The Data Exchange requirements are:

1. DE1 – Systems MUST include CPT content releases when exchanging data between clinical systems. CPT release numbers MUST be included when patient data that have been coded with CPT content is exchanged between clinical systems (eg, other EMRs, hospital information systems). The CPT release should be in the YYYYMMDD format.
2. DE2 – Systems MUST include CPT identifiers and terms when exchanging data between clinical systems. CPT® identifiers and terms MUST be included when clinical data is exchanged between electronic patient records systems. This includes the Code, Descriptor, ClinicianDescriptorId, and ClinicianDescriptor.

 

 

MODULE SEVEN: Subsets Tooling Requirements

Introduction

The previous modules described how subsets are developed, maintained, distributed, and implemented. Manually carrying out those tasks without tooling is a very time-consuming exercise and prone to errors. Based on the tasks that were identified in the previous modules, this module seeks to define the requirements a tool must have in order to effectively aid the subsets process.

Intended Audiences

The intended audiences for this module include

• Clinicians – Clinicians will be using the tooling as part of the subsets development by selecting CPT® codes and/or Clinician Descriptors that are applicable for their subsets. This module will allow them to be familiarized with some of the functionality they will be using.
• Health information management professionals – Health information management professionals will assist in conducting quality assurance checks and subsets maintenance. This module will allow them to be familiarized with some of the functionality they will be using.
• Data and Technical Analysts – If the tool will be built in-house, data and technical analysts will need to be aware of the requirements of the tool in order to develop the tool.
• Executives – Tooling is a key requirement when developing and maintaining subsets. Executives need to be aware of the tooling that is required so as to budget possible funding for developing a tool or purchasing a tool or services.

Learning Objectives

After reviewing the content in this module, the reader is expected to be able to:

• Describe the tooling requirements needed to develop and maintain subsets.

Subset Tooling Requirements

The following table provides an overview of the requirements.

The following are detailed tooling requirements that were identified in the previous modules:

1. Tooling must be able to create an initial subset from an input file.
2. Tooling must be able to create an initial subset based on CPT® sections and subheadings.
3. Tooling must be able to assign multiple users to the same set.
4. Tooling must be able to allow users to select CPT codes and Clinician Descriptors for inclusion into or exclusion from a subset.
5. Tooling must be able to compile subsets based on various rules.
6. Tooling must be able to conduct quality assurance checks and subsets maintenance using a specified CPT release based on the requirements specified in Module 4.
7. Tooling must be able to generate reports on changes including:
   1. CPT codes that have been deleted
   2. Replacement CPT codes for deleted CPT codes
   3. Clinician Descriptors that have been deleted
   4. Replacement Clinician Descriptors for changed Clinician Descriptors
8. Tooling must allow physicians and clinicians to select replacement CPT codes and Clinician Descriptors.
9. Tooling must be able to export the updated subsets in the desired format.
10. Tooling must be able to generate specified summaries from a subset already imported into the tool.
11. Tooling must be able to take a CPT content release input as a parameter.

 

NAVIGATION

Component 1: Framework

Component 2: Primer

Component 3: Assessment of Feasibility

Component 4: Licensing

Component 5: Mapping

Component 6: Subsets

Component 7: Clinical Reporting

Component 8: CPT® Link

Component 9: Technical Requirements

Component 10: Educational Material

Component 11: Terminology Management

Component 12: RBRVS (RVUs)