After playing around with the billing and looking through the code, note the following issues:
1. All the Reports->Financial (except for the Collections) have a CPT and ICD entry box. These should instead be Procedure and Diagnosis entry boxes and the code in all of these forms need to support this (appear to currently have CPT/ICD stuff hard-coded in.
2. The syndromic surveillance only works with ICD9 codes. I modified the Administraion->Fees to allow setting any code as reportable, however the Syndromic Surveillance report will still only show the ICD9 ones. So, will need to get the report to support other code sets.
3. The fee sheet only shows the code (and not the code type) when selecting a justification code. It would be more clear to also show the code type (ie. ICD9:258.12 rather than 258.12).
4. The justify sql column in the billing table should also include the code types of the codes (ie. ICD9:258.12 rather than 258.12)
5. The ar_activity table should have a code_type column since it has a code column (akin to the billing table), otherwise not clear what code set the code is actually from. Note this is something that will also need to be fixed in Z&H’s recent code submission that placed the COPAY from billing table into the ar_activity/ar_session tables.
6. Deal with all the places where, ICD9, CPT4, HCPCS or code_type id numbers are hard-coded into queries (surprisingly, there does not seem to be many of these).
I have rebased all of your commits (I left out your one integration commit, though, which we can get to later) into one and placed it on the most recent codebase (note I just committed several items to sourceforge to use the formatted sql columns rather than the raw ones): http://github.com/bradymiller/openemr/commits/mcaloon-ICD10-databaseLoadCode_5
It is testing well (I did some random sanity checks on the formatted columns which appear ok) and working. Things that should be considered before committing this to sourceforge are:
1. Consider placing keys/indexes on the code and formatted_code in the dx/proc tables to make lookups as fat as possible.
2. Migrate the sql “pieces” you use from sql directory to a sql/library directory (so users don’t get confused and try to install these pieces separately)
3. And the biggest issue is that users should be able to install/update both the ICD9 and ICD10 tables separately. For example, if a user already has ICD10 tables installed, they should still be able to install/update ICD9 tables. Whether to turn these tables off/on or do a full migration can be dealt with at Administration->Lists->‘Code Types’. By keeping these independent gives the most flexibility to practices. Potential ways to do this are to make the ICD9/ICD10 install/update mechanisms completely separate, which then nicely allows the version sql column to hold something else in the future (such as CMS for using the cms tables or WHO-<language> to hold the WHO set in a specific language etc.). Let me know your thoughts here.
Hi,
Another obvious question is whether it makes sense to include the ICD9/ICD10 files in the OpenEMR package (so, easy for users to import the codes if wanted)? These files are actually rather small, so size not an issue. I think the main issue is licensing (ie. is it ok for us to package and distribute these files from CMS? thoughts?
-brady OpenEMR
Brady,
I am looking into a consolidated UI approach to the ICD 9/10 issue of concurrent installs. I am also reviewing your post #43 above and will be back with a commit at some point soon.
I just have a question. Is there a table of icd-9 or icd-10 codes that are actually used in the problem lists? This would be a table that is updated when a problem is added to a patient record. My thinking is a practice will use a subset of these codes and, over time, a smaller table that will have what is needed 95% of the time would make lookups or finding the right code much faster.
Something I’ve found useful is to simply have a selector that shows all the codes that have been used for the current selected patient. So, for example, in the fee sheet, could have a selector that is called Previous (or something like that) which is populated by all codes (could have different selectors for each code type) that hev been used (in problem lists or billing table for the patient. The clinic wide storing of billing codes, I suppose could also be done; now that the code searching engine is centralized, wouldn’t be too tough to make this an optionable feature.
Or maybe a field that tracks frequency of use for a code so that “Common Codes” , maybe the top 20, could be displayed. Or at least codes with prior hits would be searched first.
Jack
OEMR Board
Hi…
I have activated the ICD 10 in the Administration->List-> Code types. Now when I search for ICD 10 codes in the issues, I get Empty list…Nothing comes up. I think the database is not present in the openemr. Can you help me getting the database and how to install it in the system?
Also, to clarify. The importing code works, just a couple issues to fix before it’s ready to get into sourceforge. (see posts above for more specifics).
-brady
Review:
1. The revision date appears to not be correct anymore (is using current date for both ICD9 and ICD10). Additionally it appears that a shell command is being used to get this; this will likely break on other os (such as windows); need to try to get this date via php to ensure works on all OSs.
2. Recommend not populating the revision_version in standardized_tables_trackyet , since info is not helpful. This can be used in future to track whether version is cms vs who (and if different language) to allow simple changing of the database. Allowing this will be key to make it easy to add support for ICD9/10 databases of different languages. Also, it appears you are populating this in the SNOMED/RXNORM tables with the date, which recommend against (again, plan to use this in the future to old language information for SNOMED etc.)
3. Recommend placing keys/indexes on the dx_code and formatted_dx_code in the following tables: icd9_dx_code, icd9_sg_code, icd10_dx_order_code
4. Recommend placing keys/indexes on the pcs_code column in the iicd10_pcs_order_code table.
And a completely optional thing is to combine all the import scripts into one (they are already one script anyways), and have ability to select, which one via a selector. For example, could have a link ‘Import Codes’ in Adsministration, which took to page where user could select ICD9,ICD10,SNOMED,RXNORM from a selector. Note this is just an idea and is outside the scope of what you are doing, so don’t feel inclined to do this. Dealing with my issues above are easily enough to get this code into the openemr codebase.
