Problems with diagnostic pointers on HCFA-1500

sourdoughpablo wrote on Tuesday, December 13, 2016:

I usually list two CPT codes for a patient visit: An office visit code and a procedure code (Osteopathic Manual Medicine).

In OpenEMR if I enter four diagnoses for the first CPT (the office visit or E&M code), they are listed first in the diagnosis list within OpenEMR. If I point to all of them (well, the maximum I can point to is 4), they are printed first in the HCFA section 21 as “ABCD”.
Then the diagnoses for the second CPT code (the OMM code) will list farther down on the diagnosis list, and will be printed sequentially in the HCFA section 21 (as “EFGH” etc.) The diagnostic codes that I point to for the CPT code will be listed first, followed by other secondary diagnostic codes.

The above arrangement gives me some control over the sequence of diagnoses in HCFA 21, which “tell a story” to the staff at the insurance company.

However, Medicare only wants me to point to ONE diagnostic code for each line item CPT code in Section 24E. And in OpenEMR, if I point to the fifth diagnostic code in the list to justify my OMM code, the software doesn’t create a reference to “E” in HCFA 24E. Instead, it “promotes” that ICD10 code to slot B in section 21, and then refers to it as “B” in section 24E. This “demotes” the secondary diagnosis codes for the E&M billing to slots C, D, and E, behind the first OMM diagnostic code, scrambling the story I’m telling to the Payor’s coding staff. They no longer have a clear clue as to which secondary Diagnostic codes apply to which Procedure codes.

This is not an ideal situation. Higher level of E&M codes require treating more than four problems, and even though you can only list 4 pointers in 24E, if these are followed by other codes in section 21, BEFORE the first code pointed to on the OMM procedure line, the relationships in the “story” are obvious.

But if the first pointer for the OMM procedure line scrambles this sequence, the story becomes ambiguous. Ambiguity in billing does not help produce timely reimbursements.

Additionally, if I edit the Fee Sheet later, changing or adding a secondary diagnostic code, this addition is put at the bottom of the sequence in the Fee Sheet and in HCFA Section 21, creating similar lack of clarity in the billing sequence. The only way I can see to rearrange the sequence is to delete and re-post the entire Fee Sheet.

Ideally I would be able to list diagnoses in the order of my choosing in within the OpenEMR fee sheet, and re-arrange that order as I edited the list, either by dragging and dropping or by having the power to toggle a specific line up or down. I could put all the diagnoses for the first CPT code line at the front of the list (primary diagnosis first), and follow them with the diagnoses for the second CPT code line (primary diagnosis first), in a WYSIWYG arrangement, controlling and KNOWING how this would sequence in the HCFA 1500 Section 21 listings A-L.

I could fill all 12 diagnostic slots (A-L) in a fixed sequence. And then I could point to any one of those slots to justify a second or third CPT code, without rearranging this (A-L) sequence. If my second CPT code is justified by pointing to the fifth diagnosis, that second line’s 24E will read “E”.

If instead I justify that second CPT code with the sixth diagnosis, then the second line’s 24E will read “F”. I could add a third CPT code line, linking it to the tenth listed diagnostic code, and the third line’s 24E would read “J”. In this case, the Insurer would read the story that in section 24, the first CPT’s primary diagnosis is “A”, with secondary diagnoses “BCDE”, and the second Procedure code line’s primary diagnosis is “F” with secondary diagnoses “GHI”, and the third CPT code line’s primary diagnosis is “J” followed by secondary diagnoses “KL”.

I’ve produced this sequencing for years with rigid DOS software and it works fine at the Payor end. It seems like it should be possible to create the same thing more flexibly with the OpenEMR system. I imagine that if you didn’t want to alter the current functionality for those who are used to it, you could add the ability to re-sequence the Fee Sheet list, and then simply create a separate circumstance where if only one line is pointed to as justification for a CPT code, the program doesn’t shuffle the sequence when printing to the HCFA form.

sourdoughpablo wrote on Tuesday, December 13, 2016:

Here are the OpenEMR and HCFA views with multiple pointers:

sourdoughpablo wrote on Tuesday, December 13, 2016:

Here are the OpenEMR and HCFA views with a single pointer per Procedure Code:

sourdoughpablo wrote on Tuesday, December 13, 2016:

Here are the OpenEMR and HCFA views after adding another E&M code secondary diagnosis to the list (using a single pointer for the primary diagnosis):

cmswest wrote on Tuesday, December 13, 2016:

hi Paul, thank you for the informative post and attachments. I wonder why your Medicare carrier is requesting 1 dx per cpt line. Maybe the OCR scanner is having trouble differentiating between the all of the letters in the string.

Also have they suggested for you to submit electronic claims which would avoid this issue entirely?

sourdoughpablo wrote on Wednesday, December 14, 2016:

sourdoughpablo wrote on Wednesday, December 14, 2016:

I’ve looked at instructions for HCFA 1500 from around the country, and in several locations, CMS is specifying one pointer per procedure line in 24E. It’s been like that here in Oregon for a long time. I’m well past the age where I wonder WHY Medicare requires a certain way of doing things.

I don’t want to submit electronically. I have a small operation here, and I don’t want to have to deal with the security issues or the HIPAA compliance issues. Until I’m absolutely forced to go electronic, I’ll continue with paper claims. At the current time I’m thinking about having my patients file the claims, and they won’t be able to do that electronically. I’m interested in OpenEMR specifically because I can use this software in house without storing data in “the cloud”.

cmswest wrote on Wednesday, December 14, 2016:

thanks Paul, I found transmittal 3083,, which confirms that the one pointer per procedure is the national instruction

dealing with the security of sending claims electronically would be just one piece of the risk assessment that is required by the security rule,

wouldn’t you have to be a non-participating provider in order for patients to send in the claims?

ps mod 25 should go on the e/m code below not the omm code

sourdoughpablo wrote on Saturday, December 17, 2016:

Right r.e. transmittal 3083.

The security rule applies to practitioners who are using the internet to transmit data used to document or justify billings. This does not apply to fax over land lines. If you never communicate financial or clinical information digitally for those purposes, then you are not a “covered entity” wrt the security rule, and you do not have to comply with HIPAA regulations in any part. Communicating with patients directly regarding their clinical situation does not make you a “covered entity”. I assume that this distinction exists because the government has the right to regulate interstate commerce, but does not have the right under the first amendment to regulate direct communication between physicians and patients.

This is a major reason that I want to use OpenEMR rather than a cloud-based solution like Charm. Charm is an elegant package and easy for a low-volume practice to implement. But with Charm, all the data is on the cloud, so any time I print up a chart note to fax to an insurance company or a lawyer, I have transmitted clinical information over the internat in order to use it for billing purposes, and I become a “covered entity” with regards to the HIPAA security rule.

I am a non-participating provider, and as such I still have the right to send paper claims in to Medicare. I’m not so sure that this means that I can have the patients send paper claims to Medicare directly—I haven’t looked into this in detail. Medicare can of course punish me by reimbursing me more slowly, or at a lower rate, if I’m not using an EMR and/or not billing them electronically.

Since I’m in solo practice rather than working in an institutional or group practice setting, I have the ability to make these choices if I choose to do so. I would imagine that this is the case for many users of OpenEMR.

Since I am not a participating provider in other managed care setups, I don’t have any specific contractual obligation to private insurers. Their contract is with the individuals they insure, not with me. So I’m not legally obligated to bill these private insurers directly. But the patient may need to give them a HCFA form as part of their billing process.

[Yes, you are right about the modifier 25 belonging with the E&M code! Thanks for pointing that out.]

cmswest wrote on Monday, December 19, 2016:

thanks for the info on the privacy and security rule exclusion; i can understand why you’d like to avoid the extra burden

here’s the patient’s claim form,

if you don’t like the reordering of the dxs you can comment out the block of offending code, openemr/Claim.class.php at 098cd94748263bb9736a619d842fafec6abb9436 · openemr/openemr · GitHub

sourdoughpablo wrote on Tuesday, December 20, 2016:

OK. I’ve commented out all the lines you highlighted. This worked well, the ICD10 codes now print on the HCFA in unshuffled form, in the same sequence that they are listed in on the fee sheet, and the CPT codes point to the appropriate lines.


My only remaining issue with this process is that if I make an error or want to modify the ICD9 codes I’m applying to this encounter, I will have to rewrite the entire sequence. If I just delete the third code and add another one, the new one will be at the end of the list.

If I had the ability to modify or replace a code line in the middle of the sequence, or to insert another code line in the middle of the sequence, I would have a more elegant control of the process, without having to delete every code below the line I want to change.

The most elegant solution would be the ability select a given code line and move it up or down in the sequence with an arrow key, in the fee sheet view.

[It appears to me that this is a new feature request, harder to solve than simply telling me to comment out some lines of code. I have no idea how easy or hard it would be to produce this functionality, but I’d love to have it available!]

This will come up from time to time, if the insurer balks at a code and we then figure out what the “correct” code would be and use it instead. And I do want that new code to fit into the correct place in the story line.

Just a variant question. Is there a way to customize the diagnosis pointer reference in the CMS 1500 Txt output as we just got a request from an insurance provider they would like A,B,C,D instead of 1,2,3,4 while other carriers are accepting the current 1,2,3,4 in the reference of pointers.

hi @Jeremiah_Ocasio, what version of OpenEMR are you working with? thank you

Hi @stephenwaite We are on version v5.0.0 (7)

hi @Jeremiah_Ocasio, the pointers are using A B C D to correspond with the diagnosis boxes above the line items on the HCFA 1500 in v 5.0.0.

You can see this on the demo,

I changed the Admin->Globals->Features to enable Prints the CMS 1500 on the Preprinted form

so you’ll see that button in the billing manager.

@stephenwaite Thanks for the demo link but after doing all updates again and resetting to what is shown in demo the install we have is still linking as numbers and not letters for the billing output or leaving it blank if autofill is disabled. Not sure if I should reset the entire update. Any suggestion would be welcome or if there is a direct file to check that would be awesome.

oh @Jeremiah_Ocasio you must have admin->globals->features->CMS 1500 Paper Form Format set to 02/12

@stephenwaite thanks that is the fix. Is there some documentation our update guys missed we should point out to double check for?

good poiny @Jeremiah_Ocasio, it should have been in the 4.2 -> 5.0 upgrade guide along with some other important settings on the wiki