badrsj wrote on Wednesday, September 02, 2009:
Hello, I intend to use this OEMR for Psychiatry.
I have kicked the tires and feel it is workable with very few changes i.e. the History form will need reworking - which does not seem difficult.
My main issue is the problem of DSM codes - Does anyone know how to do that.
As an alternate work around - if there is an option of manually entering a code - which then gets stored in the codes in the OEMR will also work.
Thanks.
bradymiller wrote on Thursday, September 03, 2009:
hey,
Can manually enter codes into the screen at Administration->Services (I’m assuming your using version 3.1.0).
-brady
mick1916 wrote on Wednesday, November 30, 2011:
I am having a problem getting DSM codes to work in OpenEMR. I have all the codes entered in the codes tables and the code type set as a diagnosis type in the code_type table but no matter what I do I cannot get it to use DSM codes for justification in the fee sheet. Is there some other table entry or setting that I need to change in order to use DSM codes for justifying claims.
Please help as I have been pulling my hair out over this.
sunsetsystems wrote on Wednesday, November 30, 2011:
In recent OpenEMR versions there’s a “Justify” column in the table of code types to indicate which type is used for justification.
mick1916 wrote on Wednesday, November 30, 2011:
I have tried that, I have even used the exact settings used for the ICD codes which work perfectly but no matter what even with DSM diagnosis selected on the fee sheet the only codes that appear are ICD9 for justification if there is also an ICD9 entry on the fee sheet or just the option to Clear the field if there is only a DSM entry on the fee sheet with the Procedure.
I have even disabled the justification option for the ICD9 code type leaving DSM as the only possible option for justification but to no avail. If there is not an ICD code on the fee sheet then the Justification drop down is blank
mick1916 wrote on Wednesday, November 30, 2011:
Sorry meant that to be ‘with DSM diagnosis as the only available option’ on the fee sheet with the procedure.
yehster wrote on Wednesday, November 30, 2011:
It actually looks like the code types used for the justify drop down is hard coded in the fee sheet javascript and it is hard coded to only ICD9. We should think about a better way to handle this!
In \openemr\interface\forms\fee_sheet\new.php around line 42 is the following:
function genDiagJS($code_type, $code) {
if ($code_type == 'ICD9') {
echo "diags.push('$code');\n";
}
}
In the meantime
If you change to something like
function genDiagJS($code_type, $code) {
if (($code_type == 'ICD9') || ($code_type == 'DSMIV) ){
change DSMIV to what ever string you used to specify the code_type, and you should be able to select the DSM codes.
Whether there are other changes needed to get billing to work correctly wish DSM codes I don’t know.
-Kevin Yeh
kevin.y@integralemr.com
mick1916 wrote on Wednesday, November 30, 2011:
I just found the hard coding myself and have changed it to the following which also works for now but your right a more permanent fix is necessary as it would be a major pain to have to change this everytime a new code type was added.
{// Generate JavaScript to build the array of diagnoses.
function genDiagJS($code_type, $code) {
if ($code_type == 'ICD9' or $code_type == 'DSMIV') {
echo "diags.push('$code');\n";
}
}
}sunsetsystems wrote on Wednesday, November 30, 2011:
Yes, given the existence of the justify attribute in the code_types table, that should be considered a bug.
mick1916 wrote on Wednesday, November 30, 2011:
I may look into trying to get any existing diagnostic codes from the Medical Problems section of the demographics to pop up on the fee sheet automatically that way if the procedure relates to an existing problem rather than a new one the user can just use it for justification and remove the unneeded ones before submitting the form. It seems a more logical way to do it as 9 times out of 10 the patient is being treated for an existing problem especially in a mental health environment.
And also getting any newly entered diagnoses being added to the Medical Problems in the Demographics section. It reduces the number of times a user has to enter the info.
mick1916 wrote on Wednesday, November 30, 2011:
As a follow up to the justification bug posts. While the temporary ‘fix’ to allow selection of DSMIV codes allows the codes to be searched and returned it also returns ICD9 codes and as such can result in an ICD9 code being improperly inserted as a DSMIV code. as an example I tried selecting DSMIV for code 541 which incidentally is an ICD code for appedicitis which it returned and allowed to be entered in the DSMIV justification field. So using the ‘fix’ is not really advisable unless the user is familiar with the proper codes in the first place.
Is it possible that ICD9 is hardcoded elsewhere as well?
Have tried various options to only return the code types initially selected on the fee sheet but ICD9 codes are always searched when trying to use DSMIV or any code not originally part of the application.
bradymiller wrote on Thursday, December 01, 2011:
Hi,
I am guessing it will be hard-coded in several places. Having it all be under the control of the code_types tables options will be a vital feature(bug fix) to remove the hard-coding of this stuff and will also be needed to support ICD10 and SNOMED coding:
http://www.open-emr.org/wiki/index.php/Diagnostic_Codes_Development
(To track the DSMIV stuff, may be a good idea to place a DSMIV part on this wiki page)
-brady
mick1916 wrote on Thursday, December 01, 2011:
Brady just an update on the ICD9/DSM problem. The hard coding was not the problem after all. The real problem was actually in the database. In the codes table the code_type field was set as a TINYINT which was preventing numbers higher than 127 from being used. I changed this to INT(11) as in the ct_id field of the code_types table, then set the DSM code type as 200 and everything works just fine. Can select any code type marked as a justification without getting any of the other types appearing.
mick1916 wrote on Thursday, December 01, 2011:
Sorry that should have been the hard coding may not have been the only problem. I had forgotten to take out the temporary fix for DSM codes. When I do its back to just ICD9 again.
I apologize will make sure I check everything twice next time.
yehster wrote on Thursday, December 01, 2011:
It would be a better approach to use 4 (four) instead of 200 as the code_type for DSMIV as that won’t require changing the schema of the codes table. There’s not really any need to allow code type id’s greater than 127 right now, as there is still “space”
Changing column types, and adding new columns to existing tables is not something that should be done lightly.
bradymiller wrote on Thursday, December 01, 2011:
Hi,
Here’s a wiki page on the code_type strategy:
http://open-emr.org/wiki/index.php/Code_Types
The goal is to move away from using the ct_id to identify and instead use the ct_key (this is how the newly implemented CVX codes work). This then gives much more flexibility for supporting upgrading etc. This i addition to removing the hardcoding of other stuff (such as the ICD9 coding jsutification) will then place OpenEMR in a position to be very flexible in regards to coding systems:
http://open-emr.org/wiki/index.php/Diagnostic_Codes_Development
Since CVX code is at 100 (which is where the “flexible”, newer code integrations should go), it probably makes sense to increase the maximum value to be greater than 127.
-brady
yehster wrote on Thursday, December 01, 2011:
Brady,
Good things to know, having both ct_id and ct_key is confusing. I guess my suggestion of 4 would be bad 
As a goal towards phasing out ct_id should we add a ct_key to the codes table? That way DSM codes can just be loaded with ct_key DSMIV. Then when any changes are made that are needed to support other code types, ct_key can be available and used rather than ct_id for determining code type?
bradymiller wrote on Friday, December 02, 2011:
Hi,
Became aware of these issues when adding the CVX codes into the official codebase. In that case, in the sql queries, joined in the code_types table in order to get at the ct_key:
$sql = "select i1.immunization_id, i1.administered_date, substring(i1.note,1,20) as immunization_note, c.code_text_short ".
" from immunizations i1 ".
" left join codes c on CAST(IFNULL(i1.cvx_code,0) AS CHAR) = c.code ".
" left join code_types ct on c.code_type = ct.ct_id ".
" where patient_id = '$pid' ".
" AND (( i1.cvx_code = '0' OR i1.cvx_code IS NULL ) OR ".
" ( (i1.cvx_code != '0' AND i1.cvx_code IS NOT NULL ) AND ct.ct_key = 'CVX') ) ".
" order by administered_date desc";
For the codes, I’m guessing there are only several types of sql queries happening, so maybe could start modularizing the sql queries into functions that utlized the ct_key from code_types and begin to integrate them into the code. Then if ever get to the point of adding ct_key directly to code_types or even removal of ct_id would be much easier since the sql calls would be centralized.
-brady
yehster wrote on Friday, December 02, 2011:
code_types has a field ct_justify, which right now although a string is basically treated as a boolean. I think the intention must have originally been to use the field to specify which fee codes can be justified by which diagnosis codes. It’s certainly not implemented that way right now, and I think is an extra layer of complexity that will just cause problems.
./interface/forms/fee_sheet/new.php: if ($code_types[$codetype]['just'] || $justify) {
./interface/billing/billing_report.php: if ($iter['id'] && $code_types[$iter['code_type']]['just']) {
./interface/reports/appt_encounter_report.php: if ($code_types[$code_type]['just']) {
By discarding the notion that we need that level of granularity, and just allowing any code needing to be justified by any “diagnosis” code, it would greatly simplify things, as the hardcoded comparison discussed above could become
if($code_types[$code_type]['diag'])
Then adding a new code_type to the database marked as being a diagnostic code would make it available to justify fees.
(this is the original code to be modified).
if ($code_type == 'ICD9') {yehster wrote on Friday, December 02, 2011:
https://github.com/yehster/openemr/commit/5aa4cc5c62445d5f7e3ac8c0d06479912f32504a
https://github.com/yehster/openemr/tree/diagnosticJustify
Ok, I implemented the fix so that any code type that is flagged as diag in the code_types table will be available for justification for any fee entry that needs to be justified.
There is a lot more work to do in order to get to “ideal behavior,” but this one fix will allow users to enable justification using other codes with only database changes and will keep working after upgrades if done this way.
-Kevin Yeh
kevin.y@integralemr.com