CPT® International
OVERVIEW
Purpose of the Technical Functional Requirements Component
Whenever a clinical terminology is adopted in an electronic system, it is necessary to define the technical functional requirements to ensure the terminology is implemented correctly and consistently. The purpose of the Technical Functional Requirements Component of the CPT® Implementation Framework Education Handbook is to define a set of minimum requirements to ensure CPT content is correctly and consistently implemented. The range of requirements includes subsets management, data capture, data storage, data display, data retrieval, and data exchange.
Intended Audiences
This component is intended for a broad range of audiences. The intended audience for each module will differ; however, the Technical Functional Requirements Component is mainly intended for the following audiences:
- Health information management professionals
- EMR vendors
- Software developers
- Database managers
Learning Objectives
After reviewing the content in the Technical Functional Requirements Component, the reader is expected to be able to:
- Describe the goals, scope, and categories of the technical functional requirements.
- Describe the meaning of keywords used in the technical functional requirements.
- Describe the minimum files that are necessary to implement CPT content in an electronic system.
- Describe the subset management requirements when implementing CPT content in an electronic system.
- Describe the data capture requirements when implementing CPT content in an electronic system.
- Describe the data display requirements when implementing CPT content in an electronic system.
- Describe the types of data retrieval functionality that must be supported in an electronic system.
- Describe the types of CPT content that must be included when exchanging patient data.
Modules
The Technical Functional Requirements Component includes seven modules. These modules describe six categories of requirements to correctly and consistently implement CPT content in an electronic system.
Module One: Introduction to Technical Functional Requirements – An introduction to the goals, scope, and categories of the requirements, as well as keywords used in the requirements and the required files.
Module Two: Subsets Management – Requirements for how CPT® subsets are managed.
Module Three: Data Capture – Requirements for searching and entering CPT content into patient records.
Module Four: Data Storage – Requirements for storing CPT identifiers into patient records.
Module Five: Data Display – Requirements for displaying CPT descriptors from patient records.
Module Six: Data Retrieval – Requirements for retrieving patient data recorded with CPT content.
Module Seven: Data Exchange – Requirements for exchanging patient data recorded with CPT content with other electronic systems.
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 Technical Functional Requirements
Introduction
This module introduces the goals, scope, and categories of the technical functional requirements. This module also explains the meaning of keywords used in the technical functional requirements as well as the files that are required to implement CPT® content.
Using Clinician Descriptors at the point of data capture is the recommended method of adopting and implementing CPT content because it provides language that clinicians are familiar with as well as an increased level of granularity over the CPT Long Descriptors. The use of subsets to ensure the CPT content is relevant for specific groups of users is also recommended. As such, the technical functional requirements center on the use of Clinician Descriptors and subsets. For additional information on subsets, refer to the Subsets Component of the CPT Implementation Framework Education Handbook.
Intended Audiences
This module is intended for all audiences as it provides an introduction to the technical functional requirements.
Learning Objectives
After reviewing the content in this module, the reader is expected to be able to:
- Describe the goals, scope, and categories of the technical functional requirements.
- Define the meaning of keywords used in the technical functional requirements.
- Describe the minimum files that are necessary to implement CPT content in an electronic system.
Introduction to Technical Functional Requirements
Goals of the Technical Functional Requirements
There are three main goals for enumerating technical functional requirements:
- To provide users with the minimum requirements of how CPT content should be implemented in an electronic system.
- To ensure that CPT content is correctly implemented in electronic systems.
- To ensure that CPT content is consistently implemented across electronic systems.
Scope of the Technical Functional Requirements
CPT content can be implemented as a primary terminology (ie, at the point of care), or as a secondary terminology (eg, abstraction and maps). The Technical Functional Requirements Component focuses on the use of CPT content as a primary terminology for use at the point of care.
Categories of Technical Functional Requirements
There are six categories of technical functional requirements for implementing CPT content described in the modules that follow:
- Module Two: Subsets Management – Requirements for how CPT subsets are managed.
- Module Three: Data Capture – Requirements for searching and entering CPT content into patient records.
- Module Four: Data Storage – Requirements for storing CPT identifiers into patient records.
- Module Five: Data Display – Requirements for displaying CPT descriptors from patient records.
- Module Six: Data Retrieval – Requirements for retrieving patient data recorded with CPT content.
- Module Seven: Data Exchange – Requirements for exchanging patient data recorded with CPT content with other electronic systems.
Subsets Management can be viewed from an electronic system’s configuration or settings perspective while Data Capture, Data Display, and Data Retrieval can be viewed from an electronic system’s front-end interface. Data Storage and Data Exchange focus on the back-end database and interoperability functionality.
Language
The language employed in these technical functional requirements is in line with the standard keywords used in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2119, "Key words for use in RFCs to Indicate Requirement Levels."[1] The keywords are shown in the following table.
CPT Files
In order to successfully adopt and implement CPT content in an electronic system, certain CPT content files are necessary. These files are derivatives of those found in CPT® Link and the Standard Data files. The examples shown here are provided only as a guide. The first two files are specific to the implementation of CPT subsets while the six other files are mandatory.
The sample specifications for the Subsets and Subset Members files are shown below. The other files are described in detail in the CPT® Link Component of the CPT® Implementation Framework Education Handbook.
For simplicity, only three data types are defined here:
- Numeric – Column contains only numeric characters.
- Text – Column contains alphanumeric characters.
- Date – Column contains a value in the form of YYYYMMDD.
Subsets
The subsets file lists the CPT subsets that are available for use. A sample specification is shown in the following table.
The following table shows sample rows for the subsets file.
The subset members file lists the CPT codes and Clinician Descriptors for each subset. A sample specification is shown in the following table.
The following table shows sample rows for the subsets members file.
MODULE TWO: Subsets Management
Introduction
The overall purpose of using subsets is usually to facilitate the adoption and implementation of a terminology. Clinical terminologies often contain thousands if not hundreds of thousands of terms. In the CPT® content, there are approximately 10,000 CPT codes and almost 28,000 Clinician Descriptors. The use of subsets can help to narrow down the content that is relevant for a specific use case. Subsets can contain just a few descriptors, or may contain thousands of descriptors, depending on the purpose of the subsets. Subsets can also help to facilitate discussions with physicians/doctors about their content by demonstrating that the content is relevant to them. The purpose of this module is to define the technical functional requirements for using subsets.
If an organization is not implementing subsets, proceed to the next module, Module 3: Data Capture.
For more information on subsets, refer to the Subsets Component in the CPT® Implementation Framework Education Handbook.
Intended Audiences
The intended audiences for this module include
- EMR vendors
- Software developers
- Database managers
Learning Objective
After reviewing the content in this module, the reader is expected to be able to:
- Describe the subsets management requirements when implementing CPT content in an electronic system.
Subsets Management
The following table summarizes the Subsets Management requirements.
SM1 - Systems MUST Have Functions to Import Subsets and Supporting Files
Systems MUST have functions to import CPT® subsets and supporting files. The context is that these subsets are national or local, organizational, or vendor subsets that were developed for use across a specific jurisdiction to standardize the use of CPT content and improve data quality. The types of files may vary depending on the complexity of the implementation, but it should generally include the following files:
For additional information on these files, refer to the CPT® Link Component of the CPT® Implementation Framework Education Handbook.
SM2 - Systems Must Have Functions to Create, Edit, and Delete Local Subsets and Subset Members
Users MUST also be allowed to develop their own local subsets and to manage the CPT codes, descriptors, and Clinician Descriptors that are included in their subsets. There MUST be interfaces as described in DC3 and DC4 to identify relevant Clinician Descriptors for inclusion in the subsets.
SM3 - Systems Must Have Functions to View Information About a Subset
To help users understand their subsets, systems MUST allow users to view information about a subset including:
- Subset date of publication
- CPT content release date
- Total number of active and inactive CPT codes contained in the subset
- Total number of active and inactive 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 able to view a list of CPT codes and Clinician Descriptors that were added, changed, and inactivated since the previous update.
SM4 - Systems MUST Not Allow Users to Modify CPT Codes or Descriptors
One of the purposes of using CPT content is to ensure the consistency of language used to document procedures and services. As such, users MUST NOT be allowed to change any CPT codes and descriptors.
SM5 - 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 recording procedures and services into patient records. Users MUST be allowed to select multiple subsets and MUST be allowed to select only active subsets.
The following figure shows a sample interface of how a user can select multiple subsets.
MODULE THREE: Data Capture
Introduction
Data capture refers to the event in which CPT® descriptors are used to document a procedure or service in a patient record. While the requirements were developed with the intention of point-of-care data capture, these requirements are also applicable to the use of CPT content as a secondary terminology.
Intended Audiences
The intended audiences for this module include
- EMR vendors
- Software developers
Learning Objective
After reviewing the content in this module, the reader is expected to be able to:
- Describe the data capture requirements when implementing CPT content in an electronic system.
Data Capture
The following table summarizes the Data Capture requirements.
DC1 - Systems MUST Allow Only Active CPT Content to Be Used
With each release of CPT content, there are CPT codes and Clinician Descriptors that are inactivated. Inactivated CPT codes and Clinician Descriptors MUST NOT be used for data capture. Therefore, at the point of data capture, users MUST be allowed to search and browse only active Clinician Descriptors for active CPT codes of a specified CPT content release to be used to document a procedure or service in a patient record.
DC2 - Systems MUST Allow Searching by Specific Subsets
Users MUST be allowed to search for Clinician Descriptors in specific subsets as specified in requirement SM5. The purpose of confining searches to specific subsets is to ensure that only relevant Clinician Descriptors are retrieved. If a user has selected multiple sets, the system must ensure the search results do not show the same Clinician Descriptor multiple times.
DC3 - Systems MUST Allow Users to Search CPT Codes
While it is expected that users will use Clinician Descriptors for data capture, there is the possibility that some users who are very familiar with CPT® content may choose to locate a Clinician Descriptor by searching for a CPT code as it may be more efficient. As such, users MUST be able to search subsets using CPT codes and Clinician Descriptors. The searches may be activated either via autocomplete functionality or click (or enter) to search.
The recommended search algorithms include a combination of (1) exact match, (2) phrase match, (3) all match, (4) starts with match, (5) wildcard match, and (6) partial match. The recommended sorting algorithm includes a combination of (1) by relevance, (2) by length of descriptors in ascending order, and (3) alphabetically.
Clinician Descriptors that are reported frequently or may be in a favorite list MAY also be shown as one of the first results. Proprietary search algorithms may also be used as long as the relevant search results may be retrieved. The CPT code SHOULD be displayed with the Clinician Descriptor.
For example, there are 19 Clinician Descriptors that refer to "mastectomy":
Search results should place emphasis on the relevance as well as the length. For example, a search for "mastectomy" SHOULD retrieve the following as the top results:
Other Clinician Descriptors that contain "mastectomy" may also be relevant, but the procedures with more details SHOULD be given less priority as they contain more details than required from the search term.
When a search is done by a CPT® code, the associated Clinician Descriptors SHOULD be displayed alphabetically. For example, if a search is done for the CPT code 13120 - Repair, complex, scalp, arms, and/or legs; 1.1 cm to 2.5 cm, the associated Clinician Descriptors SHOULD be displayed in alphabetical order:
- Complex repair of arm, 1.1-2.5 cm
- Complex repair of leg, 1.1-2.5 cm
- Complex repair of scalp, 1.1-2.5 cm
DC4 - Systems MUST Allow Users to Browse CPT Codes in a List and Hierarchical Structure
In addition to searching for Clinician Descriptors, users MUST be allowed to browse the descriptors in a subset in both a list form and in a hierarchical structure.
The list MUST display the CPT® code, Long Descriptor, and Clinician Descriptor. The list should be sorted by CPT code but can be sorted by descriptor or Clinician Descriptor.
The hierarchical structure MUST follow the structure of the CPT® Professional Edition book, which contains a maximum of six headings including the CPT content section. For example, the following list shows the location of code 13120 in the CPT content structure.
- Surgery (10021-69990)
- Surgical Procedures on the Integumentary System (10030-19499)
- Surgical Repair (Closure) Procedures on the Integumentary System (12001-16036)
- Repair—Complex Procedures on the Integumentary System (13100-13160)
- 13120 - Repair, complex, scalp, arms, and/or legs; 1.1 cm to 2.5 cm
- Complex repair of arm, 1.1-2.5 cm
- Complex repair of leg, 1.1-2.5 cm
- Complex repair of scalp, 1.1-2.5 cm
- 13120 - Repair, complex, scalp, arms, and/or legs; 1.1 cm to 2.5 cm
- Adjacent Tissue Transfer or Rearrangement Procedures on the Integumentary System (14000-14350)
- Skin Replacement Surgery (15002-15278)
- Repair—Complex Procedures on the Integumentary System (13100-13160)
- Surgical Repair (Closure) Procedures on the Integumentary System (12001-16036)
- Surgical Procedures on the Integumentary System (10030-19499)
DC5 - Systems MUST Support the Use of Modifiers
In addition to codes and descriptors, CPT content includes modifiers that are available to indicate the service or procedure performed has been altered by some circumstance but not changed in its definition.
Examples of CPT modifiers include:
When a Clinician Descriptor is selected for entry into a patient record, systems MUST show only modifiers that are applicable to the CPT code the Clinician Descriptor belongs to. Systems MUST also allow for the selection of up to six modifiers for a CPT code.
The following table shows an example of modifiers that are applicable to CPT content sections.
DC6 - Systems MUST Validate CPT Codes and Modifiers (Where Applicable) Against the CPT Guidelines
Systems MUST have functions in place to validate CPT codes (and modifiers, where applicable) when they are entered into a patient record. Systems MUST also display reasons why a CPT code (and modifiers, where applicable) is rejected. Providing the reasons why the use of a CPT code and/or modifier is rejected can help educate users on how to correctly report services and procedures rendered.
The main types of guideline (rules) validations are:
- Ensure an add-on procedure is used in conjunction with a primary procedure
- Ensure two or more CPT codes can be reported in conjunction with each other
- Ensure modifiers can be used with a CPT code
For additional information on CPT guidelines, refer to the CPT® Link Component, Module 4, of the CPT® Implementation Framework Education Handbook.
DC7 - Systems MUST NOT Alter Codes or Descriptors
Systems MUST ensure that codes and descriptors (both Clinician Descriptors and Long Descriptors) must be displayed as shown in the distribution files without any alterations or truncations. The longest Clinician Descriptors are approximately 500 characters.
For example, "Anesthesia for bronchoscopy" MUST NOT be altered to the following (or any other variation):
- ANESTHESIA FOR BRONCHOSCOPY (transformation to uppercase)
- anesthesia for bronchoscopy (transformation to lowercase)
- Anes for bronchoscopy (abbreviated)
- Bronchoscopy, anesthesia (re-ordered)
DC8 - Systems SHOULD Display Additional Information for CPT Codes
Additional information about a Clinician Descriptor SHOULD be available in the form of tooltips, dialog boxes, or popups. This can include the CPT code, Long Descriptor, guidelines (rules), and units. While this is not a mandatory requirement, the additional information may be useful for users when they are choosing a service or procedure to report.
For example, when the cursor is placed over a Clinician Descriptor, Fine needle aspiration biopsy using computed tomography (CT) guidance for each additional lesion, in a list of search results, the following information should be displayed:
DC9 - Systems SHOULD Support 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. Autocomplete can aid data capture as potentially relevant descriptors can be displayed without users having to type full search phrases.
DC10 - 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. This feedback will improve the usability of the systems for users.
DC11 - Systems SHOULD Highlight Search Keywords
When search results are shown, search keywords SHOULD be highlighted. The highlighting can be in the form of bolded text or different colors. The highlighting of search keywords SHOULD be implemented in both autocomplete searches and click (or enter) searches. Highlighted search keywords can make it easier for users to understand why the search results are shown. This is useful as lexical matching is usually the primary method of identifying relevant search results.
For example, when searching for the words "exc les," the search keywords can be highlighted:
- 42104 - Excision of lesion of uvula
- 41110 - Excision of lesion of tongue
- 42104 - Excision of lesion of palate
- 66130 - Excision of lesion of sclera
- 67840 - Excision of lesion of eyelid
MODULE FOUR: Data Storage
Introduction
When Clinician Descriptors are recorded into a patient record, it is important to store the appropriate identifiers and descriptors. This module describes the data storage requirements that ensure what is entered in data capture is available for data display.
Intended Audiences
The intended audiences for this module include
- EMR vendors
- Software developers
- Database managers
Learning Objective
After reviewing the content in this module, the reader is expected to be able to:
- Describe the data storage requirements when implementing CPT® content in an electronic system.
Data Storage
The following table summarizes the Data Storage requirements.
The following table lists the types of CPT content described in the data storage requirements and their optionality.
DS1 - Systems MUST Store Clinician Descriptor Identifiers and Modifiers (Where Applicable) in Patient Records
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 the Clinician Descriptor identifier. This is to ensure that the procedure or service stored at the patient record is at the appropriate level of granularity. Systems may be designed to store internal identifiers instead of the Clinician Descriptor identifiers as long as they are linked directly to the Clinician Descriptor identifiers. CPT® codes and Clinician Descriptors are immutably linked (ie, a Clinician Descriptor identifier is always linked to a CPT code and is never reassigned to another CPT code); therefore, it is also not mandatory to store the CPT code.
For example, if the Clinician Descriptor 10032178 – Shaving of dermal lesion of arm, 0.5 cm or less was used to record a procedure done, it is not adequate to record the CPT code 11300, as the Long Descriptor, Shaving of epidermal or dermal lesion, single lesion, trunk, arms or legs; lesion diameter 0.5 cm or less, refers to either epidermal or dermal, and to three possible body sites. Therefore, it is important to always record the Clinician Descriptor identifier because it provides a higher level of granularity than the CPT code.
CPT codes may also be reported with no modifier codes or up to 6 modifier codes. These 2-character modifier codes MUST also be stored in patient records.
DS2 - Systems SHOULD Store Clinician Descriptors and CPT Codes in Patient Records
In addition to storing CPT Clinician Descriptor identifiers in patient records, storing the Clinician Descriptor associated with the identifier can help improve the performance of data display.
For example, in addition to storing the Clinician Descriptor identifier 10032178, a patient record can also include the Clinician Descriptor Shaving of dermal lesion of arm, 0.5 cm or less. This can help improve the performance of the displaying a patient record as the Clinician Descriptor associated with the Clinician Descriptor identifiers does not have to be retrieved from a separate table or lookup.
In addition, the CPT code may also be stored in the patient record to help improve the performance of data retrieval.
For example, if a physician/doctor wants to retrieve all patient records that refer to 11300 – Shaving of epidermal or dermal lesion, single lesion, trunk, arms or legs; lesion diameter 0.5 cm or less, a system does not need to query a separate table or lookup to determine what Clinician Descriptors are associated with the CPT code 11300; it can retrieve the patient records directly that contain the CPT code 11300.
DS3 - Systems MAY Store the CPT® Link Concept Identifier for the CPT Code and Long Descriptors in Patient Records
Systems MAY also store the CPT® Link concept identifier and Long Descriptor to improve the performance of displaying the Long Descriptor and retrieving guidelines, citations, coding tips, and other related CPT content.
MODULE FIVE: Data Display
Introduction
Ensuring that procedures and services documented with CPT® content are displayed accurately in patient records is important. This module describes the requirements for data display.
Intended Audiences
The intended audiences for this module include
- EMR vendors
- Software developers
Learning Objective
After reviewing the content in this module, the reader is expected to be able to:
- Describe the data display requirements when implementing CPT content in an electronic system.
Data Display
The following table summarizes the Data Display requirements.
DD1 - Systems MUST Display the Same Descriptor Used in Data Capture When Displaying the Descriptor in Individual Patient Records
Users MUST be able to view the exact Clinician Descriptor that was entered into a patient record at the point of data capture. Clinician Descriptors are more granular than Long Descriptors, so it is NOT appropriate to capture a patient record with Clinician Descriptor and display the Long Descriptor (instead of the Clinician Descriptor) in an individual patient record.
DD2 - Systems MUST Display the Long Descriptor for Aggregated Patient Records
When displaying patient records by CPT code, the Long Descriptor MUST be used as the Clinician Descriptors represent more granular procedures. The aggregation of Clinician Descriptors to the CPT code level is done usually when grouping results.
For example, the Long Descriptor Shaving of epidermal or dermal lesion, single lesion, trunk, arms or legs; lesion diameter 0.5 cm or less MUST be used when patient records are displayed for CPT code 11300. Additional breakdowns may be done by Clinician Descriptors, as shown in the following table.
MODULE SIX: Data Retrieval
Introduction
Data retrieval is different from data display as it goes beyond just displaying the descriptors associated with the CPT® identifiers stored in patient records. Data retrieval is also different from data capture, where the search is focused on lexical matches based on the descriptors. Being able to retrieve CPT content stored in patient records is important to realizing the benefits of using CPT content. In this context, data retrieval includes, but is not limited to, patient case queries, patient recalls, reports, and research. It can be in the form of a single identifier or aggregation using CPT content headings. Inactivated CPT content stored in patient records should also be retrievable.
Intended Audiences
The intended audiences for this module include
- EMR vendors
- Software developers
Learning Objective
After reviewing the content in this module, the reader is expected to be able to:
- Describe the types of data retrieval functionality that must be supported in an electronic system.
Data Retrieval
The following table summarizes the Data Retrieval requirements.
DR1 - Systems MUST Support Retrieval of Patient Records Using CPT Identifiers
Systems MUST have search capabilities for retrieving patient records using CPT codes and Clinician Descriptor identifiers. Data retrieval interfaces MUST have similar searching and browsing functionality to those described in the Data Capture module to identify the appropriate CPT codes.
In Module 1, the sample subset members referred to the CPT code 14301 - Adjacent tissue transfer or rearrangement, any area; defect 30.1 sq cm to 60.0 sq cm, which had two corresponding Clinician Descriptors:
- 10041790 - Rearrangement of adjacent tissue for repair of defect, 30.1-60.0 sq cm
- 10041791 - Transfer of adjacent tissue for repair of defect, 30.1-60.0 sq cm
DR2 - Systems MUST Support Retrieval of Patient Records Using CPT Content Headings
Systems MUST have search capabilities for aggregating patient records using CPT® content sections and headings. Data retrieval interfaces MUST have similar searching and browsing functionality to those described in the Data Capture module to identify the appropriate CPT codes.
The following table shows an extract of the CPT content sections and headings. Systems MUST have the functionality to retrieve all Clinician Descriptors at any of the levels and to retrieve the patient records associated with those Clinician Descriptors.
The CPT content sections and headings can be derived from the Property table in CPT® Link or the file Comprehensive. For more information on the Property table, refer to the CPT® Link Component from the CPT Implementation Framework Education Handbook. The following table describes the structure of the Comprehensive file as well as an example.
The columns H1 Descriptor, H2 Descriptor, H3 Descriptor, H4 Descriptor, H5 Descriptor, and H6 Descriptor can be used to aggregate to the CPT content section and headings. It should be noted that the Comprehensive file does not include the concept identifiers for the headings and it also does not include the heading summary.
DR3 - Systems MUST Support Retrieval of Patient Records That Contain Inactivated CPT Codes
Systems MUST be able to include CPT codes that have been inactivated but were previously used in patient records via the historical relationships.
Within CPT® Link, there are two types of relationships that can be used to identify potential replacement CPT codes for inactivated CPT codes. The Historical relationships are used to link deleted CPT codes with replacement CPT codes:
An example of the "refer to" historical relationships is the inactivated CPT code 10022 – Fine needle aspiration; with imaging guidance, which can be used to identify potential replacement CPT codes:
Therefore, when searching for patient records using CPT® codes 10005-10012, patient records that include CPT code 10022 should also be retrieved. For example, when searching for patients that had a 10005 – Fine needle aspiration biopsy, including ultrasound guidance; first lesion, patient records with 10022 – Fine needle aspiration; with imaging guidance MUST also be retrieved as possible matches.
An example of the "replaced to" historical relationships for inactivated CPT code 0374T – Exposure adaptive behavior treatment with protocol modification requiring two or more technicians for severe maladaptive behavior(s); each additional 30 minutes of technicians’ time face-to-face with patient (List separately in addition to code for primary procedure) is CPT code 0373T, which can be used to identify the replacement CPT code:
While CPT® Link includes a historical link between inactivated CPT codes and replacement CPT codes, CPT® Link does not include historical links between inactivated Clinician Descriptors.
It should be noted that inactivated Clinician Descriptors do not have any historical relationships. For example, in 2019, the Clinician Descriptor 10016945 – Airway resistance by impulse oscillometry for CPT code 94728 was replaced with 10031520 – Measurement of airway resistance by impulse oscillometry, but CPT content does not include a historical link between the Clinician Descriptor identifiers 10031520 and 10016945. When a query is done for CPT code 94728, any patient records with Clinician Descriptors that have been inactivated MUST also be retrieved.
MODULE SEVEN: Data Exchange
Introduction
In the context of the technical functional requirements, data exchange refers to the sending and receiving of CPT® content encoded patient data coded between electronic systems. The purpose of this module is to describe the data fields that must, should, and may be exchanged between the sending and receiving electronic systems.
Intended Audiences
The intended audiences for this module include
- EMR vendors
- Software developers
Learning Objective
After reviewing the content in this module, the reader is expected to be able to:
- Describe the types of CPT content that must be included when exchanging patient data.
Data Exchange
The following table summarizes the Data Exchange requirements.
The following table lists the types of CPT content described in the data exchange requirements and their optionality.
DE1 - Systems MUST Include CPT® Code, Long Descriptor, Clinician Descriptor Identifier, Clinician Descriptor, and Modifier Code and Descriptors (Where Applicable) When Exchanging Data Between Electronic Systems
CPT® codes may be inactivated, Long Descriptors may be changed, and Clinician Descriptors may be inactivated over time (Clinician Descriptors are never changed, only inactivated). As such, it is important to include all relevant descriptors when exchanging data between electronic systems to ensure the receiving system is able to display a human-readable descriptor that corresponds to the CPT code and Clinician Descriptor identifier. As procedures may be reported with both CPT codes and modifier codes, it is also important to include the modifier codes and modifier descriptors.
DE2 - Systems SHOULD Include the CPT Content Release Date When Exchanging Data Between Electronic Systems
A receiving electronic system may conduct validation checks on the CPT code and Clinician Descriptor identifier that is received. As CPT codes and Clinician Descriptors may be inactivated over time, including the CPT content release date may help the receiving system correctly validate the incoming CPT identifiers.
DE3 - Systems MAY Include the CPT® Link Concept Identifier for the CPT Code When Exchanging Data Between Electronic Systems
CPT® Link concept identifiers may be useful to a receiving system depending on the functionality available in the receiving electronic system. For example, if CPT® Link is used in the receiving electronic system, the concept identifier may be useful in retrieving CPT content stored in CPT® Link such as guidelines, citations, and coding tips. However, retrieving the concept identifier from a CPT code or Clinician Descriptor identifier is a straightforward task, which is why this requirement is an optional requirement.
NAVIGATION
Component 3: Assessment of Feasibility
Component 7: Clinical Reporting
Component 9: Technical Requirements
Component 10: Educational Material