Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
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.
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?
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.
Ask clients to follow Kevin's advice.
Can have some very strange mal-alignments when the printer is not set to "Actual Size".
also kevin mccormick had offered up the command line version which is handy on linux systems
lpr-cups -P <printer queue="" name=""> -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
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?
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.
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?
usually only need 1 dx to get a claim paid!
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.
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.
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.
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?
Added 6 ICD's to one CPT in the 2103 Demo and still unable to reproduce the problem.
Jeff Guillory Jr.
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
The above solution was found in the settings. Changing the settings to the new format fixed the problem. My apologies.
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
Demo site is only on 4.1.2 patch 3. I can't test for the HCFA 02-12
Try the 2099 Demo or the 2103 Demo cited above.
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.
I pulled your fix into the Master Branch.
Should this go in the next 4.1.2 patch?
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.
No, it's the justify column in the billing table I'm referring to not the codes themselves.
Old justify method:
Current justify method:
Just check the billing table in our production copy from 2 years ago (probably running 4.1.0 at the time). Each line that had a CPT code in the Code column had a corresponding ICD-9 code (xxx.xx) in the Justify column. Data from yesterday had ICD9|xxx.xx in the Justify column.
Same result after just entering and justifying a charge for Phil Belford in the 4.1.1 Demo. Line 7 which led with a CPT code has the Justify column populated, while line 8 which led with an ICD-9 code has the Justify column empty. See attachments.
Both images in the above post are broken, therefore it is impossible to comment on them. In both attachments above, lines with fees are associated with populated Justify columns. It is unclear what is the difference between old and Current except the designation, ICD|.
If the screenshots had been expanded, the lines with Justify values probably would have led with CPT codes. It would make no sense to have the Justify column populated for a line that leads with an ICD code or with a copy, because there is no reason to justify an ICD code or a copay.
The 4.1.0 Demo is no longer available.
Attempted to replicate problem in the weekly Demo, 2103, but failed.
Removing the code type for an ICD-9 code caused it to be unavailable in the Fee Sheet, so that is not it.
Even with the removal of the text, ICD9, from the Code Type column of the billing table and using an encounter date from 2011; all elements populated correctly in the CMS 1500 02-12. See attachments.
The 4.1.0 Demo's have been shut down. There isn't a way to test there.
Thus far, it does not appear that we have a bug on our hands. Users, reporting this problem, have an idiosyncrasy that has yet to be identified.
The package for Windows uses XAMPP 1.8.2 for OpenEMR 4.1.2, while the older package used XAMPP 1.7.3. I wonder if version differences is contributing to the problem.