Diagnosis Pointers Explained
In the last 17 years, I have been asked a number of times to explain diagnosis pointers. While diagnosis pointers are simple once you understand them, sometimes they are difficult to explain, especially to those outside the claims world. The best way I can think of for now is to put together this diagnosis pointer FAQ. If you have any additions, corrections or would like me to answer other questions, please leave a comment.
What are Diagnosis Pointers?
Diagnosis Pointers are used to describe sometimes complex many to many relationships between submitted diagnosis and service line treatment information on health claims and encounters.
Where did diagnosis pointers come from? Why are diagnosis pointers used?
Pointers originated with paper claims. As you can see from the image, there is not a lot of room left in the service line area for diagnosis codes. Instead, the user just enters a number that corresponds with the diagnosis code they are “pointing” to. When EDI started to be used for claims, pointers were a natural fit for two reasons: First, to keep things the same no matter how the data was submitted (electronic or paper) and second to keep EDI “lean”. Transmitting data used to be expensive and charged by the character. Using pointers meant that no diagnosis code ever had to be listed and transmitted more than once.
Why not just list all the Diagnosis at the line?
A properly coded claim often has diagnosis that are not pointed to, but still collected during the encounter. For a service that is somewhat generic like an office visit, the patient may have come in because they had the flu, but ended up getting a full evaluation that showed a previous lower leg amputation and perhaps diabetes management. While the office visit did not address the leg specifically, capturing the diagnosis is still very important.
Are Diagnosis Pointers used in Institutional Claims?
No. Diagnosis pointers are only used in Professional Claims.
Who uses Diagnosis Pointers?
Claims departments use them to determine if they will pay the claim. After loading the pricing for that provider and determining eligibility and coverage, claims decides if the treatment is covered. Among other decisions being made is whether the treatment is covered for the diagnosis. For something simple like an office visit, almost any reason will do, but for something more specific they must match. If the diagnosis is broken toe and the treatment is removed kidney, the claim will not be paid. This is a way to prevent fraud and also a way to avoid paying expensive claims that are really a result of a keying error.
How many diagnosis pointers can there be?
On any given service line there are up to 4. In current EDI (version 5010 of the 837P) the value must be between 1 and 12.
What if more than four (4) diagnosis relate to the treatment?
The coder who is submitting the claim at the provider picks the 4 best and does not point to the others. The idea is to give enough detail / justification for the service being claimed to actually be paid. If one pointer will do, then there is very little reason to point to more codes. In the off chance other diagnosis are relevant to the treatment, they are still available to the examiner at the insurance company who is doing the adjudication – they just are not specifically pointed to.
Why should HEDIS, Medicare Revenue efforts or the new Health Insurance Exchange ignore Diagnosis Pointers?
Pointers are limited to 4 or less per line and average around 1.3 per line. This means that if HEDIS or Revenue only used the codes that were pointed to, codes that are crucial to HEDIS measures or HCC calculations would be dropped. A doctor who did a proper, comprehensive E&M for a patient would almost certainly have the information ignored when processing.
Besides pointers what other limitations are present on Diagnosis Code Submission?
The total number of submittable codes vary by transmission type.
- EDI 837 v4010 Professional: 8
- EDI 837 v5010 Professional: 12
- Current Paper Claim, Professional: 4
- EDI 837 v4010 Institutional: 12
- EDI 837 v5010 Institutional: 25
- Current Paper Claim, Institutional: 18
- ICE (no limit)
Is there any reason Medicare Revenue has to pay attention to pointers?
Certain systems may require them to be submittable data. For example, CMS’s EDPS system that replaces the RAPS system for risk adjustment has them as a required field to be able to submit to the system.
What does it mean when an insurance company asks for numeric diagnosis pointers?
The latest paper form – the CMS 1500 required after April 2014 – has switched from numbers to letters. Meanwhile the EDI (Electronic Data Interchange) files still require a number from 1-12. This puts a small disconnect between the paper data and the electronic. If one were to put a letter into the pointer field of the EDI file, it will reject. Many payers import native EDI or a flattened form of it to put claims into their system. Even if the claim came in as paper, many times it is automatically converted to EDI using OCR / scanning. Done correctly, the OCR vendor should do a crosswalk from Alpha (A-L) to numeric (1-12). This means that if there is an “A” a “1” is put into the EDI field and if there is a “C” a “3” would be sent. Most claims systems will not be updated either so any hand entered claims will have to be converted as well.
The new form can be found here: http://www.cms.gov/Medicare/CMS-Forms/CMS-Forms/Downloads/CMS1500.pdf
Does cross-walking data from a letter pointer to a numeric pointer “change” the data?
Short answer: no. Compliance officers at health plans are often very worried about having a source of truth for the claim. Crosswalks are used throughout data integration projects for a number of reasons. Sometimes it is something as simple as formatting a date from MMDDCCYY to CCYYMMDD. Other times it might be reason codes so that internal codes used in the claims payment process can be understood by those outside by converting them to CARC codes. It is a good idea to document any cross walks or formatting, but the fundamental data has not changed at all.
Paper_Inbox 