Click here for more sample CPC practice exam questions with Full Rationale Answers

Practice Exam

Click here for more sample CPC practice exam questions and answers with full rationale

Practice Exam

CPC Practice Exam and Study Guide Package

Practice Exam

What makes a good CPC Practice Exam? Questions and Answers with Full Rationale

CPC Exam Review Video

Laureen shows you her proprietary “Bubbling and Highlighting Technique”

Download your Free copy of my "Medical Coding From Home Ebook" at the top left corner of this page

Practice Exam

2016 CPC Practice Exam Answer Key 150 Questions With Full Rationale (HCPCS, ICD-9-CM, ICD-10, CPT Codes) Click here for more sample CPC practice exam questions with Full Rationale Answers

Practice Exam

Click here for more sample CPC practice exam questions and answers with full rationale

Tag Archives: guidelines

New clinical criteria definitions in 2017 Official Guidelines up the ante for coders

New clinical criteria definitions in 2017 Official Guidelines up the ante for coders

by Laura Legg, RHIT, CCS, CDIP, and AHIMA-approved ICD-10-CM/PCS trainer

The new guideline for code assignment and clinical criteria in the 2017 ICD-10-CM Official Guidelines for Coding and Reporting does not mean clinical documentation improvement is going away; instead it just upped the ante for continued improvement.

Up the ante means to increase the costs, risks, or considerations involved in taking an action or reaching a conclusion. With the new coding guideline for clinical validation that went into effect October 1, the stakes remain high for the diagnoses documented by the physician to be clearly and consistently demonstrated in the clinical documentation.

It is not that the information was not there before, but now the issue is finally getting attention. When clinical documentation is absent, coders are instructed to query the provider for clarification that the condition was present. But what are we to do if the clinical indicators are not clearly documented? For HIM professionals who deal with payer denials, this has been a haunting issue for a very long time.

The ICD-10-CM Official Guidelines for Coding and Reporting are the foundation from which coders assign codes. Coders need to review the new guidelines in detail to understand the changes and implications for their facilities.

The Centers for Disease Control and Prevention published these new guidelines which can be read in their entirety here: www.cdc.gov/nchs/data/icd/10cmguidelines_2017_final.pdf.

 

Taking a closer look

The coding guideline for section A.19 (code assignment and clinical criteria) has been labeled as controversial and, at this point, we have more questions than answers. Denials issued by payers due to the absence, or perceived absence, of clinical indicators by which the payer lowers the DRG is now being called DRG downgrading and it’s getting attention.

The code assignment and clinical criteria states:

 

Physicians and other providers document a patient’s condition based on past experience and what the clinician learned in medical school, which often differs from clinician to clinician. When you put a patient in front of a group of clinicians you will most likely get differing documentation. So how do we fix that?

The diagnosis of sepsis is a good example. There does not appear to be a universally accepted and consistently applied definition for the condition of sepsis.

In a patient record with the principal diagnosis code of sepsis, followed by the code for the localized infection, pneumonia, a payer denial could occur.

Payer denials often deny the sepsis diagnosis code stating that "the diagnosis of sepsis was not supported by the clinical evidence. Therefore, as a result of this review, the diagnosis code A41.9 [sepsis, unspecified organism] has been removed and the principal diagnosis re-sequenced to code J18.9 [pneumonia, unspecified organism] for pneumonia and to the lower paying DRG 193." This is now being referred to as a DRG downgrade. DRG downgrades can occur for different reasons including both DRG coding changes and clinical validation downgrades.

 

What is a coder to do?

What is a coder to do when a physician documents a diagnosis that may not be supported by the clinical circumstances reflected in the patient’s chart? Facilities and coding teams should develop guidance and be sure they fully understand the content and the impact of this coding guideline to coding practices.

Remember the section that reads: "the assignment of a diagnosis code is based on the provider’s diagnostic statement that the condition exists. The provider’s statement that the patient has a particular condition is sufficient."

This represents a catch-22. If the diagnosis is not clinically validated, both recovery auditors (RA), as well as commercial insurance auditors, are going to deny the claim. On the other hand, if coders or the facility decide not to report the diagnosis, they are in violation of the coding guidelines, which is also a major problem.

AHIMA’s 2016 Clinical Documentation Toolkit offers this advice:

The toolkit is available here: http://bok.ahima.org/PdfView?oid=301829.

 

Increasing clinical documentation

As the healthcare industry experiences an increased number of external audits, both federal and private, the need to up the ante on clinical documentation has become essential. The answer is not to let this guidance prompt lazy documentation, which has far reaching consequences, but to use it as a catalyst for improvement.

The goal of any clinical documentation improvement (CDI) program is to ensure a complete and accurate patient record, and this cannot be done without the presence of documentation supporting the clinical indicators and clear and consistent documentation regarding the condition. The provider’s documentation of their full thought process will accomplish this. If medical staff can come together and agree upon a definition for a certain condition, they can begin the process of being consistent with how the description is presented in the patient record.

CDI specialists and coders should not use the new guideline as an excuse not to query. Coders are not clinicians and, therefore, should not be expected to evaluate clinical criteria. Coding and CDI were separate functions, but, as audits from outside organizations expand, there is more emphasis on correct coding, DRG assignment, and the use of clinical criteria to support the reported codes, which means these entities need to work together.

The American Hospital Association’s Coding Clinic for ICD-10 instructs coders not to use background clinical information contained in their responses for code assignment. This information is only provided so the coders can make a judgment to query where there is incomplete documentation. Coders and CDI staff should review all chart documentation and data, and query when necessary to clarify inconsistencies in physician documentation.

Query the provider to support their diagnostic and procedural documentation by making a specific reference to the clinical basis of the diagnosis, and also by noting the absence of specific expected criteria such as radiographic findings, lab values, or patient manifestations.

External auditors in turn need to be following the same rules and coding guidelines as we do. Reviewers for facilities plagued by copious denials are finding auditors making up their own rules, using obsolete or outdated criteria, and clearly not understanding basic terminology used in the 2017 IPPS final rule.

DRG downgrading may be illegal, and some states intend to find out using state level legislation. Downgrading is, at the very least, disregarding the physician’s clinical judgment. We can’t forget who has eyes on the patient. Coders and CDI specialists should take documentation one step further and ask physicians to document their thought processes, the clinical indicators they are seeing, and their rationale for diagnosis determination.

Remember, coding is not based on clinical criteria. Coders cannot disregard physician documentation based on clinical indicators in the patient record, so, we will always need to ensure documentation is complete, accurate, and reflective of the patient’s clinical condition.

 

Editor’s Note:

Laura Legg, RHIT, CCS, CDIP, is an AHIMA-approved ICD-10-CM/PCS trainer, and director of HIM optimization at Healthcare Resource Group in Spokane Valley, Washington. For questions, please contact editor Amanda Tyler at atyler@hcpro.com. Opinions expressed are that of the author and do not represent HCPro or ACDIS.

HCPro.com – Briefings on Coding Compliance Strategies

Updated 2017 ICD-10-CM guidelines come ‘with’ controversial changes

Updated 2017 ICD-10-CM guidelines come ‘with’ controversial changes

by Shannon E. McCall, RHIA, CCS, CCS-P, CPC, CPC-I, CEMC, CRC, CCDS

 

Just like the lyrics to the popular Gap Band song say, "You dropped a bomb on me… I won’t forget it," there are definitely some changes in the 2017 ICD-10-CM Official Guidelines for Coding and Reporting that some of us may wish the Cooperating Parties will forget were ever mentioned.

Generally, changes to the guidelines are minor and rarely cause the chaos and confusion that will certainly ensue with the most recent release, effective October 1. This release includes some contradictory guidance and downright concerning statements that appear as if no one really thought through the repercussions. These revisions will certainly have an impact not only on code assignment, but also specifically on reimbursement.

With

The guidelines state:

The classification presumes a causal relationship between the two conditions linked by these terms in the Alphabetic Index or Tabular List. These conditions should be coded as related even in the absence of provider documentation explicitly linking them, unless the documentation clearly states the conditions are unrelated. For conditions not specifically linked by these relational terms in the classification, provider documentation must link the conditions in order to code them as related.

 

I consider this paragraph the most controversial addition to the guidelines. We’ll look at the impact the guideline has on previous examples relating to conditions such as diabetes mellitus, hypertensive heart disease, and some other conditions.

The guidance most commonly discussed is that for "diabetes with," which was stated in the AHA’s Coding Clinic for ICD-10-CM/PCS, First Quarter 2016, and reconfirmed in the following quarter. To summarize, the AHA guidance stated:

The classification assumes a cause-and-effect relationship between diabetes and certain diseases of the kidneys, nerves, and circulatory system and ANY condition listed under the term "with" in the Alphabetic Index is intended to be interpreted as a related condition/manifestation.

 

It appears that someone has never looked in the actual ICD-10-CM index file, because all conditions related to diabetes mellitus are indented under the word "with," not just isolated ones as in the ICD-9-CM manual.

Here is the comparison (from the ICD-9-CM index):

Diabetes, diabetic (brittle) (congenital) (familial) (mellitus) (severe) (slight) (without complication) 250.0

Compare to this excerpt from the ICD-10-CM Alphabetic Index:

The most surprising aspect to me in the repeated guidance is the contradiction to not assume a relationship between osteomyelitis and diabetes mellitus, which Coding Clinic originally stated in Fourth Quarter 2013 and reiterated in First Quarter 2016, writing:

ICD-10-CM does not presume a linkage between diabetes and osteomyelitis. The provider will need to document a linkage or relationship between the two conditions before it can be coded as such.

 

Coders understood back in 2013 to not assume relationships between diabetes and other conditions that coexist in a diabetic patient. But this recent guidance creates more questions than answers. This very specific guidance about osteomyelitis leads me to imagine the scenario of a patient who has a relationship created between osteomyelitis and diabetes mellitus by a provider documenting "osteomyelitis due to diabetes mellitus." What codes would be reported?

The correct answer would be to assign the code for other specified complication (e.g., E11.69) since there is no entry specifically for osteomyelitis under diabetes mellitus. It would be classified to the "other" category per the ICD-10-CM conventions. If we examine this a bit closer, E11.69 is listed under the word "with" in the Alphabetic Index.

So, is it assumed or not? The guidance and guidelines directly contradict each other.

Some have argued that the ICD-9-CM index included a specific entry for diabetes with osteomyelitis, and I agree that the word "osteomyelitis" is there in black and white, but take a look at the code title: 250.8 (other specified manifestation of diabetes mellitus). There wasn’t a specific code in ICD-9-CM that said "diabetes with osteomyelitis," just like there isn’t in ICD-10-CM.

Diabetes, diabetic (brittle) (congenital) (familial) (mellitus) (severe) (slight) (without complication) 250.0

I suggest if the Cooperating Parties truly plan on keeping osteomyelitis separate, there should be a separate entry in the Alphabetic Index where it is not at the second indentation level under the word "with," but is under diabetes as a main term with a singular indentation.

The "with" guidance extends much further than I think the Cooperating Parties have considered. For risk-adjusted plans, the assumption of linking diabetes and other related conditions (acute and/or chronic) without necessitating providers document it will have a direct impact on a patient’s overall risk score.

The risk score uses many factors, but chronic conditions like diabetes mellitus are a key component in determining how much CMS should pay an insurance plan for care for Medicare beneficiaries covered under plans like Medicare Advantage (i.e., Part C). Being able to assume a relationship is a major change and will ultimately have a big impact on spending for any risk-adjusted plan, considering diabetes is such a common condition.

The reason this hasn’t really been considered an issue yet is that Medicare Advantage data is compiled based on the previous year’s diagnosis codes to prospectively estimate spending in the upcoming year.

Therefore, CMS is currently using ICD-9-CM data for encounters through September 30, 2015. Hopefully, this new guidance valid for encounters as of January 1, 2016, will be considered a factor, because patients with diabetic complications are certain to increase.

If the word "with" couldn’t get any more controversial, it ventured out of the endocrine system to the very "heart" of every coder’s cardinal rule. We learned, as fledgling coders, to never assume heart disease (like heart failure) is directly related to hypertension unless the provider documents the two conditions as related, like hypertensive heart failure or heart failure due to hypertension.

Well, no more, my friends?this is the dawn of a new age of coding. We can assume away, not only for hypertension and (chronic) kidney involvement, but also for hypertension and heart involvement because they are both indented under the word "with" in the Alphabetic Index.

The revised guideline states (bolding is mine)’:

The classification presumes a causal relationship between hypertension and heart involvement and between hypertension and kidney involvement, as the two conditions are linked by the term "with" in the Alphabetic Index. These conditions should be coded as related even in the absence of provider documentation explicitly linking them, unless the documentation clearly states the conditions are unrelated.

 

Please notice that the past statement does identify that if the provider specifically states another cause, the conditions should be coded as unrelated.

The larger issue I have with assuming anything under "with" is seen in the ICD-10-CM Alphabetic Index and is yet another direct contradiction to the guidelines. If the guidance regarding "with" is truly universal within the Alphabetic Index, then it implies a relationship for diseases extending beyond just diabetes mellitus and hypertensive heart disease. For example, it seems that coders could begin to assume, based on the guidelines, that patients who have sepsis with a coexistence of organ dysfunction have severe sepsis, even though the guidelines specifically state "an acute organ dysfunction must be associated with the sepsis in order to assign the severe sepsis code."

Who knew that a little word like "with" could cause so many issues?

 

Excludes1 notes

The guidelines also include an update on reporting Excludes1 conditions. The updated guidelines state:

An exception to the Excludes1 definition is the circumstance when the two conditions are unrelated to each other. If it is not clear whether the two conditions involving an Excludes1 note are related or not, query the provider.

 

The Excludes1 conventions clarify what was addressed in the interim guidance provided in October 2015 and in the AHA Coding Clinic for ICD-10-CM/PCS, Fourth Quarter 2015, to address situations where Excludes1 notes should be considered Excludes2 or had other exceptions. Category I63 (cerebral infarction) excludes subcategory I69.3- (sequela of cerebral infarction). This guidance directly contradicted the guidelines for Chapter 9, which state: "Codes from category I69 may be assigned on a health care record with codes from I60-I67, if the patient has a current cerebrovascular disease and deficits from an old cerebrovascular disease."

For 2017, subcategory I69.3- has been revised to be included in an Excludes2 note. Exceptions have been added to the guidelines when the exclusion was for a category that may include a number of different conditions, like the "other" category. Some of those inclusive conditions should never be coded with the diagnosis the Excludes1 note appears under, others may be completely unrelated.

This opens the door for a third-party auditor to debate the application of the Excludes1 note if coding the two conditions separately creates a financial impact.

 

Edito’?s note

McCall is the director of HIM and coding for HCPro, a division of BLR, in Middleton, Massachusetts. She oversees all of the Certified Coder Boot Camp programs. McCall works with hospitals, medical practices, and other healthcare providers on a wide range of coding-related custom education sessions. For more information, see www.hcprobootcamps.com.a

HCPro.com – Briefings on APCs

Coding standards and guidelines

Good software development organizations usually develop their own coding standards and guidelines depending on what best suits their organization and the type of products they develop.

The following are some representative coding standards.

Rules for limiting the use of global: These rules list what types of data can be declared global and what cannot.

Contents of the headers preceding codes for different modules: The information contained in the headers of different modules should be standard for an organization. The exact format in which the header information is organized in the header can also be specified. The following are some standard header data:

• Name of the module.

• Date on which the module was created.

• Author’s name.

• Modification history.

• Synopsis of the module.

• Different functions supported, along with their input/output parameters.

• Global variables accessed/modified by the module.

 

Naming conventions for global variables, local variables, and constant identifiers: A possible naming convention can be that global variable names always start with a capital letter, local variable names are made of small letters, and constant names are always capital letters.

Error return conventions and exception handling mechanisms: The way error conditions are reported by different functions in a program are handled should be standard within an organization. For example, different functions while encountering an error condition should either return a 0 or 1 consistently.

The following are some representative coding guidelines recommended by many software development organizations.

Do not use a coding style that is too clever or too difficult to understand: Code should be easy to understand. Many inexperienced engineers actually take pride in writing cryptic and incomprehensible code. Clever coding can obscure meaning of the code and hamper understanding. It also makes maintenance difficult.

Avoid obscure side effects: The side effects of a function call include modification of parameters passed by reference, modification of global variables, and I/O operations. An obscure side effect is one that is not obvious from a casual examination of the code. Obscure side effects make it difficult to understand a piece of code. For example, if a global variable is changed obscurely in a called module or some file I/O is performed which is difficult to infer from the function’s name and header information, it becomes difficult for anybody trying to understand the code.

Do not use an identifier for multiple purposes: Programmers often use the same identifier to denote several temporary entities. For example, some programmers use a temporary loop variable for computing and a storing the final result. The rationale that is usually given by these programmers for such multiple uses of variables is memory efficiency, e.g. three variables use up three memory locations, whereas the same variable used in three different ways uses just one memory location. However, there are several things wrong with this approach and hence should be avoided. Some of the problems caused by use of variables for multiple purposes as follows:

• Each variable should be given a descriptive name indicating its purpose. This is not possible if an identifier is used for multiple purposes. Use of a variable for multiple purposes can lead to confusion and make it difficult for somebody trying to read and understand the code.

 

• Use of variables for multiple purposes usually makes future enhancements more difficult.

 

The code should be well-documented: As a rule of thumb, there must be at least one comment line on the average for every three-source line.

The length of any function should not exceed 10 source lines: A function that is very lengthy is usually very difficult to understand as it probably carries out many different functions. For the same reason, lengthy functions are likely to have disproportionately larger number of bugs.

Do not use goto statements: Use of goto statements makes a program unstructured and makes it very difficult to understand.

Itech troubleshooter is an advanced web development, high skilled professional software Solution Company located in New Delhi founded by, PRABHAKAR MISHRA in the year 2008.The company provides vast range of services to each and every customer in reaching their respective targeted spectators and their valuable information in fix and on steady affordable price. Today, you can easily get a lot of quality services by this company on just dialing a call to the company which includes services like website designing , web application development , Application development , Maintenance , Re-engineering , Flash development , SEO , SEO Services ,  Computer Networking , Wireless Networking , Data Recovery , ERP Solution .