cmswest wrote on Tuesday, April 28, 2015:
hi, i’m brain storming a way to add an extra pop up after you’ve searched for an icd9 code that would show the possible mappings from icd10_gem_dx_9_10
would it be advantageous to use ct_rel in the code_types table ?
tmccormi wrote on Wednesday, April 29, 2015:
I think there may be a icd9 to icd10 mapping table out there in the wild, be good to use one that is already created and managed by some community…
might be able to do something with this: http://www.icd10data.com/Convert
http://www.cms.gov/Medicare/Coding/ICD10/2014-ICD-10-CM-and-GEMs.html
The second one has downloadable tables 9 to 10 and 10 to 9.
Example: ICD-9-CM to ICD-10-CM GEM
ICD-9-CM code 902.41 has the following GEM entry:
Source Target Flags
90241 S35403A 10000
902.41 Injury to renal artery
To S35.403A Unspecified injury of unspecified renal artery, initial encounter
•
The source system is less specific than the target system along the
laterality axis of classification
• The target system classification contains both specific and less specific
laterality translation alternatives
• Only the less specific laterality translation alternative is included as an
entry
Not included in ICD-9-CM to ICD-10-CM GEM
S35.401A Unspecified injury of right renal artery, initial encounter
S35.402A Unspecified injury of left renal artery, initial encounter
cmswest wrote on Wednesday, April 29, 2015:
the table i mentioned, icd10_gem_dx_9_10 is the GEM file from cms.gov, and is already available to be imported into the openemr database through the external dataload mechanism
fsgl wrote on Wednesday, April 29, 2015:
One of the uses of Related to is for the billing of pharmaceuticals. The NDC of the drug appears in the shaded section of Box 24.
If a practice inadvertently adds another ICD10 code to the Related to box, the claim will be rejected.
What is the reason for alternate codes?
A practice rarely uses the codes for other specialities, so the entire dataset is extraneous stuff clogging the hard drive.
In anticipation of this October, a practice can use the online converter for the smaller subset.
We are not paid more if more than one diagnosis code is used, thus life is simpler to stick to one code for billing.
cmswest wrote on Wednesday, April 29, 2015:
thanks fsgl for the ndc connection
i thought it would be a nice addition to see the mappings inside openemr especially since we already have access to the file and some practices don’t have a small subset of codes
edit: this would be for selecting one dx code for the claim, so one could select from the mapped list of icd10 codes
fsgl wrote on Wednesday, April 29, 2015:
Glad to return the favor.
If the practice must have all 68,000 codes in the database; they’ll need extra time for the transition.
Had a quick look at the GEM text file. It’s a minute list, not even a one-to-one mapping.
Fortunately the ICD10 search can be done by short descriptor. If the entire dataset has been installed, the billing clerk should not have a great deal of difficulty choosing one to justify a charge.
cmswest wrote on Tuesday, May 05, 2015:
i posted the wrong file name earlier, this is the pertinent file which i believe would be very useful to integrate
fsgl wrote on Tuesday, May 05, 2015:
Way better than the GEM file.
Only drawback is the lack of descriptors. Many billing clerks don’t recognize the ICD9 code based on the 4 or 5 digits alone.
There is not a convenient place to put the file in Fee Sheet, unless you create something new.
In the interim would suggest that the clients be given a copy of the text file as reference. Very easy to scroll down the list.
One other suggestion. Coding would be simpler if the practice narrows the choices.
For example, 365.11, Chronic Open Angle Glaucoma, has 5 mappings. Using H40.11XO is better than deciding if it’s mild, moderate, severe or indeterminate. If there is no direct bearing on reimbursement, there is no reason to go through all the hassle.
