I find it a little weird that both the procedure and diagnosis ICD-9 and ICD-10 codes can overlap. For example (according to the spec on page 4) E2345 is a valid diagnosis code in both systems, and 1234 is a valid procedure code in both systems. Given that the previous ICD-9 system is fairly prevalent, having a disjoint code system for both systems seems to me like an obvious thing to do.

There are also plenty of transcriptional errors that happen through human nature. It's not uncommon (as mentioned on page 20) for people to mistake numbers for letters (.e.g O vs 0). Having a code specification that "position 1 can be numeric or alphabetical" is just asking for errors. It's also not uncommon for characters to be accidentally flipped around (27 vs 72), duplicated (317 vs 3117), or deleted (A12B042 vs A12B42). To get that right (or as correct as possible), you need to have real-time checking of data entry (e.g. making fields red until they match expected values), additional verification ("you entered E2345 -- Abstract thought process with chance of rain. Is this correct?"), and preferably multiple people attempting to enter the same data. An auditor (verifying that entered data is consistent with the original document) is also helpful in the process.

Also, with 70,000ish codes in the new system, you're introducing ambiguity that wasn't present before. It's mentioned on page 17 that "each correct coding answer was assigned a one (1) and each incorrect answer got a zero (0)" [which is where this 63% statistic came from]. Someone who is familiar with the previous system might look at a case and say, "oh, that's clearly E2345", but then discover that E2435 maps to 2 or 3 different codes in the new system. Determining "correctness" by a single binary value hides the degree of incorrectness. The wave explanations (page 18, 19) suggest ambiguity to have been a factor in a reasonable number of misclassifications.

All that accounted for, I think that a 63% accuracy based on a binary correct/incorrect decision is pretty good. A document like this one should really have broken that correctness statistic down to at least transcription and coding errors, but the coding errors should be also broken down further in terms of the closeness of diagnosis.

There are many clinical registries now in use especially for high risk procedures such as cardiac surgery and NOF surgery and also for high mortality outcomes such as cancer care. These registries are considered very expensive, even though they have been shown to have a remarkable effect on healthcare improvement , but they can be put to work to pay for themselves on this very area. We have employed a pragmatic auditing process between our cardiac surgical outcomes registry (used for outcomes monitoring & QI/ research projects) and our coders. This occurred as a response to the implementation of Activity Based Funding and was thought of by one of our Clinical Data Mangers who's background includes nursing and HIMO. Each month the most significant procedures from our clinical register are audited against the DRGs produced by the coders. Information on inconsistencies is provided to the coders who examine the records to work out where& how coding errors occurred and make corrections. Improvement in coding has occurred and our Clinical Information Service has saved hundreds of thousands of dollars per year for a few hours auditing per month. This can't fix all coding error issues, but a friendly monitoring process with a feedback mechanism such as this certainly can improve coding precision particularly for high resource care episodes where other clinical data is captured electronically. See link to a presentation on how registry data can be put to work:

https://www.researchgate.net/publication/255991005_Squeezing_Juice_from_Clinical_Data_Repositories_Information_for_Patient_Management_andABF_Revenue_HISA_Data_Governance_Conference_2012_Melbourne?ev=prf_pub

Conference Paper Squeezing Juice from Clinical Data Repositories: ��Informati...