ICD10 code

system · February 25, 2012, 2:49am

garcianc wrote on Saturday, February 25, 2012:

We are working on a recent implementation of OpenEMR in Kenya, version 4.1.0 with Patch 7. We are currently finishing user training and will be going live soon.

The site was very interested in using ICD10 codes instead of ICD9 so we added the code type and loaded the codes into the “codes” table. Unfortunately, it was not that easy (as it should have been) because of numerous hard-coded references to “ICD9” in the OpenEMR code. However, we have enough working functionality to continue.

We have already found and changed a few instances of hard-coded “ICD9” in the OpenEMR code (e.g. in find_code_popup.php) and know of many other occurrences in other files (e.g. codes.php, code_types.inc.php) that we have not changed yet.

Before we embarked on any major changes/customizations I would like to know if someone has already done this and was willing to share the code changes and any other gotchas (i.e. database changes).

Otherwise, is anyone else interested in a modified version of OpenEMR with ICD10 support? If this sort of thing is allowed. We may need help testing.

Thanks,
Nelson

system · February 25, 2012, 9:05am

bradymiller wrote on Saturday, February 25, 2012:

Hi,

Making OpenEMR much more flexible (ie. remove the hard-coding) would be extremely helpful. Here’s a quick entry regarding ICD10 support on the wiki:
http://www.open-emr.org/wiki/index.php/Diagnostic_Codes_Development#ICD10
Another pertinent page is here:
http://www.open-emr.org/wiki/index.php/Code_Types

The big gotcha to watch out for and start implementing is to use the ct_key rather than the ct_id in future code (see second wiki page above for details on this).

If you post your code(best to do via git/gitub repo;ask if need further detaisl on how to do this), community would be happy to provide guidance on the most effective way to implement your changes in a fashion that will work for the official codebase (advantage to this are you will avoid pain on version upgrades and you will likely get a bunch of testers since international users have been requesting this feature for awhile now).

-brady

system · February 25, 2012, 6:07pm

garcianc wrote on Saturday, February 25, 2012:

Thanks for the reply and for the link Brady. I will get to work, albeit somewhat slowly, and when I am ready I will ask about the git/gitub process.

I was thinking of something similar to what you mentioned regarding the use of ct_key to avoid literal references to “ICD9” in the code.

My thoughts were more along the lines of a global configuration variable (i.e. something like “facilityDxCodeType” - which is really a ct_key) which the code would reference instead of using “ICD9”, “ICD10”, “ICD10-CM”, “ICD10-CA”, etc. or any other local variant that an implementer might want to use.

The codes that we obtained in spreadsheet form from, I am assuming, the Kenya Ministry of Health, numbered 10,935 rows, which is already less than the 16,000+ number in the WHO ICD10 list. Therefore, it would be nice to enable multiple variants of Dx codes to keep the code as portable as possible among the international community.

Thanks again Brady.

Nelson

system · February 25, 2012, 8:46pm

garcianc wrote on Saturday, February 25, 2012:

Sorry for using this as a development log, but posting in case I am heading down the wrong path so someone can stop me.
My first modest attempt was to update a file that I had already fixed by hardcoding “ICD10” by now making it dependent on a global variable.

I added a record to the “globals” table with gl_name=“facility_dx_ct_key”, gl_index=0, and gl_value=“ICD10”. Of course, that gl_value must match a ct_key in the code_types table.

Edited line 105 of “clinical_reports.php” to read as follows:
dlgopen(’…/patient_file/encounter/find_code_popup.php?codetype=<?php echo $GLOBALS ?><?php if ($GLOBALS) echo ‘&?codetype=IPPF’ ?>’, ‘_blank’, 500, 400);

Note: I realize that I could have combined the two PHP snippets into one <?php > tag but I wanted to preserve the original code as much as possible for now.

Tested the file by login into OpenEMR, going to Reports->Clients->Clinical and clicking inside the “Problem DX” box to bring up the popup. This brought up “ICD10” as the default (which we wanted). Just to be sure, changed the facility_dx_ct_key in the globals table back to ICD9, logged in again and “ICD9” came up as the default.

So far, so good.

system · February 26, 2012, 11:16am

bradymiller wrote on Sunday, February 26, 2012:

Hi,

My thoughts are the following:
In the code_types table, make a new entry entitled ct_active
(support to toggle this on/off can be added to adminsration->lists->code types at a later date)

Make a new library file entitled library/code_types.php and place a function called collectActiveDiagnosisSet() (the names are just suggestions; feel free to use what naming scheme you want), which simply returns the the ct_key of the entry from the code_types table that has both the ct_active and ct_diag set to one. Then you simply place the return of this function into the above find_code_popup.php call.

If we use this type of strategy, then can simply go through the code adding new functions/sql columns as needed. This should then also clear the way for SNOMED stuff also at the same time.

-brady

system · February 26, 2012, 11:34am

bradymiller wrote on Sunday, February 26, 2012:

Additionally,
The best place to add the new functions is in this script:
custom/code_types.inc.php
-brady

system · February 27, 2012, 6:46pm

garcianc wrote on Monday, February 27, 2012:

I will follow your suggestion. It might help in dealing with an issue that I have been struggling how to handle.

There are a few places where the code uses “ICD9” where we might need to maintain the ability to identify ICD9 codes for backward-compatibility. For example if we have a site that migrates from ICD9 to ICD10 and still has some records in the billing table with ICD9 codes.

For instance, take a SQL statement from Claim.class.php with a WHERE clause like this:
(code_type = ‘CPT4’ OR code_type = ‘HCPCS’ OR code_type = ‘COPAY’ OR code_type = ‘ICD9’)

If I were to substitute the ‘ICD9’ with something like $GLOBALS, as was my original plan, that would not support including both the legacy (ICD9) and the current (presumably ICD10) codes. So I was contemplating leaving the hardcoded ICD9 and adding another “OR” to that statement with a variable reference to the active code type.

However, having all the diagnostics code types in a table, even with the ct_active set to NO for all but one, should solve this issue in this case by creating a variation of the collectActiveDiagnosisSet() function that returns all diagnosis sets in the table and using it in the WHERE clause using the IN $array method (off the top of my head, not sure of this yet).

I will post an update when I get a chance to try this out.

system · February 28, 2012, 4:51am

bradymiller wrote on Tuesday, February 28, 2012:

Hi,

Sounds like you’re on the right track. Whenever you have code, suggest getting it reviewed in order to commit this to the official sourceforge codebase. Happy to continue provide guidance here and help with some of the other OpenEMR coding intricacies (like adding the tables etc.) since getting this feature working would be a huge improvement to OpenEMR. Best way to get code reviewed (and makes collaboration easy) is to use git/github and a tutorial of doing this in OpenEMR can be found here:
http://www.open-emr.org/wiki/index.php/Git_for_dummies
-brady

system · March 16, 2012, 1:19am

mcaloon wrote on Friday, March 16, 2012:

I have downloaded the raw ICD 10 files and there are a number of classifications and/or file types; Titles/Blocks/Chapters, DX (diagnosis) and SG (seem to be procedural), O (tumor based codes). As I have been reviewing the code I’ve noticed a couple of things; 1.) there are a number of filters for code types CPT which also seem to be procedural and 2.) in the code_types.inc.php file there is an association between ICD9 and CPT4. So generally my question is: “Will the ICD 10 implementation allow users to choose whether to use CPT or ICD 10 SG codes?” and specifically “Will we be implementing the UI capability to select the Title/Blocks/Chapters that could be useful in reporting and analysis (or do we manage that as metadata)?”

Maybe someone whose has some detail knowledge of the CPT coding or coding stuff in general could chime in here. Thanks.

system · March 20, 2012, 3:31am

mcaloon wrote on Tuesday, March 20, 2012:

Wiki with more details of the ICD 10 stuff from WHO

https://sourceforge.net/u/mcaloon/wiki/Home/

system · March 20, 2012, 7:48am

bradymiller wrote on Tuesday, March 20, 2012:

Hi,

Very nice to see this. Placed a link to your wiki pages here:
http://open-emr.org/wiki/index.php/Diagnostic_Codes_Development#ICD10

Anybody have ideas here:
1. Should we simply be importing the ‘Categories’ into the codes sql table?
2. Or should we treat this more like SNOMED terms and create custom tables for the different types of data (if so, is there a standard sets of tables to install like SNOMED).

thanks,
-brady
OpenEMR

system · March 20, 2012, 12:44pm

garcianc wrote on Tuesday, March 20, 2012:

Thanks for posting that mcaloon. I could have ended up going in an entirely different direction. The ICD10 file that we were given by Siaya District Hospital (SDH), Kenya contained different codes than what I see in the spreadsheets in your Wiki.

The file provided to us by SDH contained 4 data columns: DisChap, DisIndex, DisCode, and Diagnosis.

For example, for “Cholera, unspecified” they show “I” for DisChap, “A00” for DisIndex, “9” for DisCode, and the description in the Diagnosis column. I can email the file or post it online if anyone is interested.

SDH stated that the “DisIndex” column was the equivalent of the “code” in OpenEMR and, when we checked against available online databases, it made sense (http://apps.who.int/classifications/icd10/browse/2010/en#/A00.9).

After creating a code type of "101’, we turned the spreadsheet provided into something like this to update their OpenEMR database to add over 10,935 codes:
INSERT INTO `codes` (`code_text`, `code`, `code_type`, `modifier`) VALUES (‘Cholera, unspecified’,‘A00’,‘101’,‘9’);

As stated at the top of the thread, we made a couple of very minor changes to the code just to get them working, and that’s where we are today. I am still dragging my feet - sorry, lots going on.

I would be interested in finding out more and comparing notes in case there are drastically different versions of ICD10 codes published. That should give us a clearer picture on the ideas that brady is asking about.

In my opinion, it would be nice to be able to do a simple import, but the published data may dictate otherwise.

system · March 22, 2012, 6:21am

bradymiller wrote on Thursday, March 22, 2012:

Hi,
Where did you download the ICD10 codeset files from (ie. where are the official published data). Really wondering what options we have for file formats? Would be really cool to implement a importing feature that is akin to how the SNOMED and RXNORM imports happen, which shouldn’t be that tough once we know the original file format choices and the end-game plan of how to structure the data.
-brady
OpenEMR

system · March 22, 2012, 6:37am

bradymiller wrote on Thursday, March 22, 2012:

Hi,

Just answered my own question by getting an account here: http://apps.who.int/classifications

Here’s the listing of files that are available for ICD10:

Classification	                 Language	 Format
ICD-10 2010 version	         English	       ClaML (more info)
ICD-10 2010 version	         English	       Plain text tabular (more info)
ICD-10 2nd Edition / 2008	 English	       ClaML (more info)
ICD-10 2nd Edition / 2008	 English	       Plain text tabular (more info)
ICD-10 Training Package for offline use (148MB zip file)	 English	 -
ICD-O-2	                                English	       Comma separated text
ICD-O-3	                                English	       Comma separated text

Guessing a good start to get a handle on these things is the offered training package that can be downloaded.
-brady
OpenEMR

system · March 22, 2012, 3:04pm

garcianc wrote on Thursday, March 22, 2012:

I got some time (and motivation) to work on this a little bit this morning. Thanks mcaloon for the wiki post and brady for the link to download the WHO files.

The ICD10 metadata described in the download’s readme file and in the wiki here was pretty helpful. Here are a couple of notes after playing with the metadata briefly this morning:
1. It appears that the codes.txt file is missing a field (Field 3, or the type of code).
2. Other than the Title, the codes.txt file contains the chapters and blocks information that is in the other two files. Therefore, in my opinion, the only advantage of importing the chapters.txt and blocks.txt would be for human-readable lookup of their description.
3. There were 12,131 codes in the codes.txt file.
4. The codes.txt file is easily imported into MySQL.
5. If it saves anyone some time, here is a dump of the table I created from codes.txt.

Also, since I mentioned this in an earlier post, this link is for the spreadsheet provided by our site in Kenya which they had to manually fill each month summarizing all their ICD10 encounters for the month. That is what we used to create their original ICD10 update to the codes table.

I hope that helps.
- Nelson

system · March 23, 2012, 8:28pm

bradymiller wrote on Friday, March 23, 2012:

Hi,
Any idea what the oncology specific code sets are meant to be used for (ICD-O-2 and ICD-O-3)? Note codes.txt already contains neoplasm codes, but are not the same as in the ICD-O-2/3 files.
-brady
OpenEMR

system · March 24, 2012, 1:41am

mcaloon wrote on Saturday, March 24, 2012:

Brady, I did some poking around tonight and created another wiki page https://sourceforge.net/u/mcaloon/wiki/ICD%202%20-%20ICD%203/ for the team’s enjoyment There is a link on the wiki page to the WHO discussing among other points the mapping of ICD 3 to ICD 10. There is also a file on that page that defines the mapping from ICD 2 to ICD 3 oncological codes.

There are a couple of things that come to mind:

1.) Existing openEMR deployments need migration paths from there existing code table to ICD 10 code table.
2.) Some older codes have a one to many possible ICD 10 codes.

It is apparent that this needs further research and definition…

Mac

system · March 24, 2012, 1:57am

mcaloon wrote on Saturday, March 24, 2012:

I see that the ICD 3 code is really a “supplemental” coding scheme that gives more specificity to the ICD10 code regarding the topographical (location) and morphological (history) of a tumor. As I am still familiarizing myself with the openEMR code base I want to ensure that the openEMR code supports multiple codes or the ability to form an association of one or more codes related to a certain diagnosis (??). Does this make sense to any of you familiar with the code base?

Mac

system · March 24, 2012, 11:19pm

bradymiller wrote on Saturday, March 24, 2012:

Hi,

Probably the first thing to do is to make a mechanism to import the ICD10 codes into OpenEMR. My thoughts are to use the same mechanism as SNOMED/RXNORM in the interface/code_systems/standard_tables_manage.php script.
Basically:
1. Plop the zipped icd10 file (icd102010enMeta.zip) into contrib/icd10
2. Go to Administration->Other->ICD10 to get to the import script
3. Import script then:
-Unzips file
-Creates ICD10_blocks, ICD10_chapters, ICD10_codes sql tables (drops tables if already exist)
-Imports the blocks, chapters, codes into the appropriate tables

At this point will then have the complete set of ICD10 data that can also be upgraded when new ICD10 codes come out (releases are tracked in the standardized_tables_track sql table-this is how RXNORM and SNOMED releases are tracked). And can then begin to make the codebase more flexible; we’ll be able to also integrate SNOMED at the same time without much more needed effort.

The oncology terms can also be added, if needed (probably best to focus on the ICD10 ones first, though).

-brady
OpenEMR

system · March 25, 2012, 2:00am

mcaloon wrote on Sunday, March 25, 2012:

please post procedure for seeding the standardized_tables_track table with the RxNorm and Snodmed data. My table is empty.

Mac