Archive for March, 2019

Breaking Down Denials: CC/MCC Denials

Posted by Samantha Serfass on March 19, 2019 in Blog, General, News


When someone in the healthcare industry hears the word “denial”, many things can come to mind.  There are many different types and kinds of denials; what could be said about denials could fill a book. To narrow the conversation, let’s touch on one specific type of denial that has become more prevalent for hospitals in recent years. 

A documented and coded diagnosis acting as a CC or MCC for the DRG is denied by the payer with the claim that the clinical picture does not support that it is a true and valid diagnosis.  By removing the diagnosis code, the DRG is reduced, resulting in a reduced payment to the hospital.

This type of denial has been called various things which can create confusion when assigning the appropriate person to address it.

A few examples are:

  • “clinical denials” which could also mean denial of admission to an inpatient bed stating the patient’s clinical picture does not warrant inpatient care
  • “DRG denials” which could also mean the entire admission was denied, not just a denied diagnosis changing the DRG
  • “Coding denials” which tends to sound like this is a coder issue when in fact it is not a coding issue at all

Payers have learned how to target the types of inpatient discharges that lend well to this type of challenge.  Common targets include DRGs with a single CC or MCC where the CC or MCC is acute renal failure/injury, acute respiratory failure, encephalopathy, malnutrition, or sepsis.

If this is not a coding specific issue, then where does the problem lie?  The Center for Medicare and Medicaid Services (CMS) has not stated any one criterion as the official clinical criteria for all to follow.  As a result, many payers including the RACs have created their own criteria or adapted existing criteria in the industry such as AKIN (Acute Kidney Injury Network), RIFLE (Risk, Injury, Failure, Loss of kidney function, and End-stage kidney disease), or KDIGO (The Kidney Disease: Improving Global Outcomes).  Providers most often do not know what individual payer criteria is being used.  Physicians have not been educated on when additional documentation is needed to support certain conditions that they diagnose and document. 

The coding teams are stuck in the middle.   Facilities can trend what different payers are targeting and the basis of their denials.  Armed with this information, coders still cannot diagnose the patient.  Even with outlined criteria to follow, conditions documented in the record and not ruled out cannot be ignored by the coder.  The coder cannot make the determination that a documented diagnosis is not valid and choose not to code it. 

What’s a hospital to do?  Hospitals should create a team to review these types of denials and fight back whenever possible.  Some hospitals have taken the extra steps to create internal clinical guidelines to give direction and promote consistency; however, payers may still deny diagnoses based on their own criteria.  Offer as much education on the issue as possible to physicians, CDI staff, and coders.

Who should review and argue the cases? The best person to review these denials and write up an appeal letter would be the very person that documented the diagnosis in question, the physician.  However, it is a rare hospital that has a medical staff member with the time and willingness to do so.  So, the task should fall to someone with strong writing skills with a clinical background that can create a strong argument in support of a documented diagnosis by outlining the patient’s clinical picture in detail.

From a different angle: Coding was initially created for the primary purpose of statistics and research.  Coded data can play a key role in value-based care and other programs based on patient care outcomes and quality of care indicators.  While Official Coding Guidelines offer clear direction on when to assign a secondary diagnosis code, the guidelines could be a part of the problem.  The guidelines state additional conditions are coded when they affect patient care by requiring clinical evaluation, therapeutic treatment, diagnostic procedures, they extended the length of stay, or necessitate increased nursing care and/or monitoring.  But what the guidelines neglect to include are conditions that create a patient health risk for the future.

One example includes patients with morbid obesity that decline nutritional counseling or any other type of intervention.  Because the condition is not being addressed, some payers are denying it as a secondary code/s.  As patients develop obesity related conditions in the future, there will be limited data for research of obesity related health problems because the condition of obesity is not being coded now.  This also could create a problem with quality of care analysis when patients’ conditions are uncontrolled due to unaddressed obesity such as diabetes, respiratory conditions, joint problems, and cardiac disease.

 Every denial should be reviewed and where possible and appropriate, challenged.  Payers may tend to target facilities that do not argue or fight back.  Do not accept a payer’s denial at face value.  Review the case.  If there is enough clinical support in the record to argue, do so.  The continued challenge is what constitutes “enough clinical support”?  Not even CMS answers that for us.

Lisa Marks

VP of HIM Services

The Importance of Accurately Documenting Workflows

Posted by Samantha Serfass on March 6, 2019 in Blog, News

Importance of Accurately Documenting Workflow

In the mid to late 1990’s, EHR vendors started focusing on workflows– and not just the feature function of the system.  A great example of initial focus on workflows are Flex Orders.  A flex order made it possible for a provider to make another order based on the results with little navigation to other screens.  EHR vendors expanded their solution offerings by developing specialty modules with workflow as the root of the design. The goal focused on targeting the right data, for the right patient at the right time.

As EHR vendors now target smaller hospitals, they pack their implementation services with tighter timelines, while accepting the EHR vendors tools, content and workflows.  Although the hospitals may be smaller, they still have complex requirements to collect and process the data in their unique environment. While an out of the box solution from the vendor is a great start, it may not provide enough focus on workflows.

Here’s one example from an EHR vendor:

  • Five years ago, the hospital employed trainers who would own the workflows. The vendor provided Viso diagrams of workflows so the hospital trainers could modify them as design decisions were made that required the workflow to change.
  • Now the same vendor recommends hospitals outsource training roles allowing the vendor to provide the trainers. However, now they aren’t documenting them accurately, if at all.

The same software company providing the roles that own your workflow is a self-serving offering.  Rather than the software vendor modify the workflow to accommodate a hospital, the hospital is now asked to modify their workflow to adopt the software.  This isn’t always a bad approach.  However, unless a hospital makes a specific focus to evaluate workflow design, it won’t happen on its own.  The vendor is focused on getting their software live as soon as possible.

Here’s an example of the impact on the hospital.

  • Five years ago, when a hospital went live, the Visio diagrams of the workflows would be referenced for training prior to Go-live and troubleshooting after Go-Live.
  • Now based on the out of the box implementation methodology, no one has the workflow diagrams which they have been implemented and trained on.

Many top EHR vendors have implemented their software several times –why not trust the out of the box solution?  When workflows are not properly documented and tailored for the specific health organization, loss in revenue can occur.

Excite Health Partners is currently working to correct a 27-million-dollar issue due to inaccurate workflow design and supporting documentation. During the implementation, the vendor did not document the workflows, and the revenue cycle test scripts weren’t customized to the hospital’s needs.

At Go-Live, the hospital realized the workflows hadn’t been built out (or tested) for one of the modules, pre-collections. They also discovered the Medicaid billing process actually had 2 different workflows the employees were following.  90% of the revenue cycle issues came back to workflow and building the system to support the hospitals processes. Excite is now helping our client resolve these issues. Important to remember to properly design and document workflows to void these types of issues.

Todd Klein

VP EHR Services & Digital Solutions