mdavis6246 wrote on Thursday, April 10, 2014:
Upgraded to 4.1.2(5) set everything to print the new HCFA 1500 2/12 version. Everything appears ok except it skips A and starts at B when printing the ICD9 diagnosis codes in box 21. Anyone have any Idea’s? This is running under linux. Been using OpenEMR since version 3.0.
fsgl wrote on Thursday, April 10, 2014:
The 4.1.2(5) Demo has been locked out.
Generated a CMS 1500, 02-12, on my test copy (Linux Mint 16) but did not print the fictitious claim. All 3 diagnoses appear to be in their proper location. See attachment.
Are all the entries on the .pdf correct?
mdavis6246 wrote on Monday, April 14, 2014:
Everything else on the the PDF files or Txt files that are generated are correct. The only problem is that the diagnoses codes start at B instead of A. It list them all. I originally thought it was just encounters that had been entered prior to the upgrade. As I have successfully entered an encounter that did print correctly on my test appliance. However I have two providers that I help support. Different systems. One Linux and one XAMPP. They are both doing the same thing. Both having the issues on old and new encounters.
fsgl wrote on Monday, April 14, 2014:
Ask clients to follow Kevin’s advice.
Can have some very strange mal-alignments when the printer is not set to “Actual Size”.
cmswest wrote on Monday, April 14, 2014:
also kevin mccormick had offered up the command line version which is handy on linux systems
lpr-cups -P -o cpi=10 -o lpi=6 -o page-left=72 -o page-top=72 <file_name>
may just be lpr on your system instead of lpr-cups
yehster wrote on Monday, April 14, 2014:
It’s not clear to me if the original poster’s problem is simply formatting/alignment, or if it’s the actual content creation.
If the first diagnosis is actually treated as B and referenced as such, this seems like a very different problem than simple alignment. In other words if there are three pointers, they are B,C and D, rather than A,B and C. Is this more like the problem you are describing, or is it just alignment/positioning?
mdavis6246 wrote on Monday, April 14, 2014:
Sorry for the confusion It’s not an alignment problem. It’s a creation problem. The Diagnosis codes are not being placed in Column A. The box looks similiar to the following.
779.1 768.2 769.2
770.1 772.3 787.3 987.3
457.8 etc etc etc.fsgl wrote on Monday, April 14, 2014:
It’s rare that more than 3 ICD codes are ever needed to justify a CPT in an actual clinical setting. (Someone has too much free time on their hands, if that’s the case.) The 8 codes were chosen probably by way of an example.
When the clients select the first ICD code, have them use only that code to justify, say, 2 CPT codes. Ask them not to use Kevin’s Fee Sheet enhancements to keep things simple. What happens in that 1 ICD-2 CPT scenario? Does the ICD populate Box A?
I’ve tried different permutations to get Box A to be blank to no avail. Are you able to replicate the problem in the 4.1.3 Demo?
cmswest wrote on Monday, April 14, 2014:
usually only need 1 dx to get a claim paid!
mdavis6246 wrote on Tuesday, April 15, 2014:
Yes the 8 code were for example. But It’s not unusual for them to have five or more. Every claim they generate will not print in Box A. Tried single pt. multiple pt. All with same results. Will have them try with just one CPT and see what happens.
It’s very odd almost as if there is a blank icd code or something else throwing off the column count. Again this is happening to two different providers. Two different offices that are not related. One is an internist, other is family practice. They have used openemr for over three years.
yehster wrote on Tuesday, April 15, 2014:
What sort of customizations if any have been done to the system?
If there is just one ICD code, does it print starting with A or B?
“blank ICD code” seems to describe the problem. If this were my system, I would fire up xdebug and step through the code line by line.
mdavis6246 wrote on Tuesday, April 15, 2014:
There hasn’t been any customization to either system. Just upgrades. What I have found so far looking at the data and such. It appears if I clear the justification in the encounter and re-do them and save it then appears to print in Col A.
fsgl wrote on Tuesday, April 15, 2014:
Very strange.
A user should not be required to re-enter the ICD code to have it appear in Box A.
Are you using the CPT link to justify? See attachment.
There is an example of an encounter for Jane Seymour in the 2013 Demo. Justifying once with 366.16 placed the code in Box A without much to do.
Experiment in the 2103 Demo and determine if you are able to reproduce the error.
A shot in the dark: see this post from an unrelated thread about Box 24E. Is it possible that the plethora of ICD’s is blanking out Box 21 A?
4/18/14 edit
Added 6 ICD’s to one CPT in the 2103 Demo and still unable to reproduce the problem.
nursejeff wrote on Tuesday, April 29, 2014:
We have a similar problem.
Our CMS 1500 's are printing out wrong.
In Box 21, the ICD-9 codes seem to be printing in the old format. We have an ICD-9 code in section A, C and I for example, instead of A, B, C.
Also in box 24, section E, the diagnosis pointer should be to the appropriate A, B, C etc, but it has numbers in them such as 123, 3. etc.
This may have to do with my settings, if anybody can help me with this I would appreciate it. We have to print all corrections and repeals and I’m running into the deadline. Please help.
Jeff Guillory Jr.
NP Health Clinic
nursejeff wrote on Tuesday, April 29, 2014:
The above solution was found in the settings. Changing the settings to the new format fixed the problem. My apologies.
Jeff
voipbound wrote on Wednesday, April 30, 2014:
I am having a similar problem. I have only one diagnosis and it goes to the 2nd position (B) while the pointer says A. Will try the Demo site to see if it has similar problem
voipbound wrote on Wednesday, April 30, 2014:
Demo site is only on 4.1.2 patch 3. I can’t test for the HCFA 02-12
fsgl wrote on Wednesday, April 30, 2014:
Try the 2099 Demo or the 2103 Demo cited above.
datagroup wrote on Friday, May 02, 2014:
Looks like the same problem we had. We’ve submitted a patch here.
Our problem existed for diagnosis without a code type. OpenEMR now includes the code type with the diagnosis when justifying a code. If that code type is not there, the new CMS1500 justifies the codes with an empty string.
fsgl wrote on Friday, May 02, 2014:
There are two ways to add ICD codes.
They can be entered manually, because the entire dataset is not necessary for most practices. This method entails enabling ICD entry via Lists->Code Types, where the Code Type has been pre-determined as either 2 or 102.
Batch import would have a column for Code Type. Why put null in that column when it’s just as easy to put 2 for ICD-9 or 102 for ICD-10?
Processes tend to work better if they are set up properly at the beginning. Nonetheless, it is helpful to know why users are encountering this problem.