Extra codes vs. creeping complexity in the ICD-10-PCS tables

January 11th, 2019 / By Rhonda Butler

Geek alert: If you are one of those people who don’t want to know how sausages and legislation are made, you may want to skip this blog. It is pretty much “sausage-making” for the ICD-10-PCS tables.

With each update of ICD-10-PCS, new detail is created in the form of a new “value” added to a table or tables—maybe a device value for a hip prosthesis made of a new material, or a new qualifier value specifying a distinct surgical technique. When a new value is added to a table, it is combined with all the other possible values within its row of the table, to create the 7-character code and the text description that goes with it.

Any proposed addition to a PCS table must be spec’d, how narrowly or broadly to apply the new value. Applying a new value as narrowly as possible makes the PCS table visually more complex. It means splitting the table up to create one or more new rows so that the new value is included only where it is likely to be used. Applying a new value more broadly preserves the visual simplicity of the PCS table, at the cost of creating a multiplicity of new codes that are unlikely ever to be used—except by accident, which is its own additional cost.

To illustrate, I’m going to invent the simplest possible example. Say there is a proposal for an endovascular stent graft for treatment of aneurysms, made of a new material generically called Nanotech Fiber. Say this hypothetical new device is FDA approved only for use on intracranial artery aneurysms, but the manufacturers have big plans to get their product approved for arteries in the neck as well (carotid and vertebral).

Below is the PCS table with the hypothetical device value F Intraluminal Device, Nanotech Fiber applied as narrowly as possible—only for the intracranial artery. The table was already split into two rows, the second row containing the arteries of the head and neck, and the first row containing the rest of the upper arteries. Applying the new device value as narrowly as possible creates a new row in the middle of PCS table 03V, containing only the intracranial artery body part:

This results in three new codes that can be assigned for a procedure to treat intracranial aneurysm using the new nanotech fiber device, depending on the surgical approach used to get to the site:

03VG0BZ Restriction of Intracranial Artery with Nanotech Fiber Intraluminal Device, Open Approach 

03VG3BZ Restriction of Intracranial Artery with Nanotech Fiber Intraluminal Device, Percutaneous Approach 

03VG4BZ Restriction of Intracranial Artery with Nanotech Fiber Intraluminal Device, Percutaneous Endoscopic Approach

If instead of applying the new device value narrowly, we apply the new device value more broadly, we preserve the existing two-row structure of PCS table 03V, and the result looks like this:

Multiplying this change across the row of the PCS table (9x3x1x1=27) creates 27 codes instead of 3. Thankfully, no one nitpicks about the number of codes anymore, so evaluating the tradeoffs of 3 new codes isn’t about the number of codes itself, but about how the user interacts with the classification. And that of course depends on who the user is—medical records coder, data analyst, policy analyst, clinical researcher, database administrator, and so on.

A coder who uses coding software might prefer the narrow option, since the software vendor is managing complexity for them. A coder who uses a paper codebook might prefer the broad option instead, because it keeps the table from being broken up across pages. Ditto with analysts and researchers who don’t code records themselves, but often look up codes in the tables to see the coded data in its table-based context and understand what the other similar options are.  

Then there are the people who work with ICD-10-PCS as individual codes and their descriptions instead of in PCS table format. They can be payers who annually update their policies with all changes, organizations who create and maintain quality measures, and others—basically anyone who maintains a database or spreadsheet containing all PCS codes has to deal with codes as individual units. Which option do you think these people would prefer? The narrow option limits the number of new codes to those that are actually relevant for a given year. That’s a plus for policy analysts, who have to make payment decisions about new codes, even ones that aren’t likely to be assigned to a record. But what if our nanotech fiber device, approved this year for intracranial arteries, is approved the following year for arteries in the neck? The result is an update that will be done piecemeal, twice in two years instead of one and done—twice the effort for all these people.

Narrow versus broad? What do you think is better? Keep in mind, this is the smallest, simplest hypothetical I could think of. The tradeoffs of the narrow versus the broad option come up with nearly every proposal at every C&M meeting. So, the effects of choosing the narrow versus the broad option over time are not trivial. On even days I favor the narrow option, on odd days the broad option. If you have a clear preference, you’re a better geek than I.

Rhonda Butler is a clinical research manager with 3M Health Information Systems.