Inside Angle
From 3M Health Information Systems
Extra codes vs. creeping complexity in the ICD-10-PCS tables
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.
2 thoughts on “Extra codes vs. creeping complexity in the ICD-10-PCS tables”
Leave a reply
Rhonda Butler
Clinical research manager
Rhonda Butler is a clinical research manager with 3M Health Information Systems. Of the original team that developed ICD-10-PCS under contract to CMS, she is the “last nerd standing.” In…
Providers rely on coding teams who do not manually code claims. Coders rely on auto suggested coding to code the record and if the coding “looks” okay they send the claim on to billing. For this reason 3M and other CAC vendors should consider lobbying for the narrow option, with the logic being less possibility of claim coding errors. On the other hand if 3M and other CAC vendors have payer partners….then they should consider lobbying for the broad option, the logic being even if the erroneously coded claim is paid, payer post payment coding audit reviewers would capture the overpayment.
Payers can afford to overpay claims as they most likely have this built into their billion dollar operating cost margins, providers on the other hand do not have payment recoupments or the increased cost of reworking claims/accounts built into theirs.
Thank you, Mary, for taking the time to comment. This is a great real-world example of the tradeoffs between narrow and broad updates of the PCS tables, for providers and payers. When you factor in the uses of coded data for quality and research, the narrow option seems like it would be the preference for the majority of users. But then again, there is the inefficiency of tweaking the same table with small changes year after year for vendors, policy analysts, system maintainers. Of course it’s job security for people like me who work in that space, but I find it hard to just let inefficiency BE. I want to DO something about it. Thanks again for your perspective.