Industry Memo on Medicare Filtering: A To Do List

By now, MAO plans have had about a month to read and understand the July 21, 2015 “Industry Memo: Medicare Filtering” letter that was published by CMS.   The letter contained clarifications and confirmations of previously disclosed information as well as new information on the proposed rules CMS will be using to conduct risk filtering.  Some highlights of the letter are: CMS fishing expedition

  • Diagnosis received from the Encounter Data Processing System submissions will be used to calculate risk adjustment dollars for the 2015 payment year (2014 Dates of Service (DOS)) as previously disclosed.
  • CMS will apply their own filter to Encounter Data received from MAOs to determine if a diagnosis is risk adjustable.
  • After confirming and appropriate place of service, CMS will use a risk filter that is CPT only for professional encounters (no specialty codes will be considered).  The codes for 2014 DOS can be found here.
  • Institutional Inpatient encounters will have all diagnosis accepted as long as they are Bill Type 11x or 41x without treatment code filtering.
  • Institutional Outpatient encounters will also filter on bill type (8 types accepted), but also be subjected to the CPT/HCPCS filtering from professional encounters.
  • Risk adjustment calculations for PY 2015 will use Encounter data as a source of additional codes.
  • Risk adjustment calculations for PY 2016 will be a weighted average of 90% RAPS and 10% EDPS scores.
  • Plans are responsible for deleting diagnosis codes from both RAPS and the Encounter data collected and filtered  by CMS by using chart reviews.
  • The submission deadline for 2014 DOS is February 1st, 2016.

Some thoughts and recommendations

The wording of the approach for 2015 PY tells us that risk adjustment dollars won’t go DOWN as a result of the introduction of EDPS data.  While it is true that it can only go up with the addition of EDPS diagnosis, every additional EDPS sourced HCC represents additional RADV risk over what the plan allows today through risk filtering efforts.  2015 DOS / 2016 PY data will use a 90/10 weighted average on payments meaning there can be both upside and downside to risk adjustment revenue.

The biggest problem however, is that there is a lot to do and not much time to do it.  Counting back from February 1, 2016, there are five months.  Plans will have to identify differences and decide if those differences need to be deleted or not.

  • Plans should not wait for CMS to provide the MAO-004 report to indicate what codes have been used for risk adjustment from encounter data under the new rules.  It will take time to approve the proposed rules and more time to start applying the filter and actually send out the backlog of MAO-004 reports.
    • Start tracking, at the very least, diagnosis submitted by encounter for 2014 DOS submissions.  Tracking individual diagnosis would be even better.
    • Apply the proposed CMS CPT filter to come up with a potential list of Encounter Data HCCs per encounter.
    • Use Encounter data HCCs to build a table of Encounter Data Member HCCs.
    • Compare Encounter data Member HCCs to RAPS Member HCCs and identify differences as top priorities for review.  There may not be time or resources to delete every diagnosis submission difference, but if the difference does not involve an actual pick up, the plan is a bit less exposed.
    • Use your own results as a known good to compare to the results of the MAO-004 when it is finally delivered to ensure CMS is applying the filter correctly.
    • Mine RAPS process for automatic deletes and ensure these are done on both sides (e.g. Professional AMI codes like 410.xx)

Another big problem has to do with the EDI process to be used to submit chart review deletes.  It is technically difficult, cumbersome to track and still unclear in some areas.

  • CMS has specified chart review deletes use a REF segment to indicate that diagnosis codes listed be treated as deletes.  At the very least, this REF segment would mean that chart reviews would need to be either “ADDs” or “DELETEs”.  While previous CMS presentations show examples of both in the same transaction, they are not EDI x12 5010 compliant and I assume have been since abandoned.
  • These deletes are not like RAPS deletes that delete on a member level.  Instead they are tied to specific encounters.  This is a problem because. . .
  • There is typically a many to one relationship between a single chart review and many encounters.  If a plan can only delete codes related to a specific ICN, many chart review deletes will have to be sent to actually delete a diagnosis.
    • Example: A chart is reviewed that spans eight encounters.  While the doctor’s notes indicate a history of a stroke, the medical biller each time coded 410.01 as an AMI – Initial episode instead of the 412.xx that would indicate the patient had a history of stroke.  The chart review uncovered this mistake and recommended the 410.xx be deleted and the 412 be added.  To do this, at least 9 chart review transactions would have to be sent.  8 of them would have to be matched to 8 different ICNs for the deletes of the 410.xx codes and at least one more would have to be sent to add back in the 412.xx.
  • Clarification on the EDI problems and Chart review delete process has been requested from CMS.

What are your thoughts?  What is your plan doing to address these issues?  Are there important things I missed or got wrong?  What has your analysis of the CPT filter turned up as a concern?  I’ll monitor comments closely and respond quickly.

Advertisement

Understanding Diagnosis Pointers

Diagnosis Pointers Explained

Pointers 1500

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.

2014 Diagnosis pointer crosswalk:
A – 1
B – 2
C – 3
D – 4
E – 5
F – 6
G – 7
H – 8
I – 9
J – 10
K – 11
L – 12
Always happy to help answer questions here as soon as possible.  For EDI or Healthcare Data Integration projects, feel free to visit my company at www.theEDIproject.com