A number of EHR (Electronic Health Record) products feature tools that automate the process of determining the E&M (evaluation and management) code for an office visit. When these tools are properly designed and used appropriately, they result in very accurate coding supported by thorough documentation. This can result in very significant and completely justified increases in revenue, not uncommonly reaching tens of thousands of dollars. This has attracted the interest of auditors, however, including the Office of the Inspector General (the body that performs audits for CMS). There is no certification or formal evaluation process for EHR E&M coding tools. Regardless of what code is suggested by an EHR, the clinician is ultimately responsible for the code submitted for reimbursement.
Physicians who are using automated E&M coding tools should follow these three steps to ensure the codes they submit are accurate:
1. Challenge your vendor to show you how the coding tools comply with published E/M coding guidelines. Most auditors use the 1995 and 1997 Documentation Guidelines for Evaluation and Management Services (these can be downloaded from the CMS website: http://www.cms.gov/). The vendor should be able to tell you exactly how the tools capture E&M related information from each section of the note, including the HPI, Past Medical History, Family History, Social History, Review of Systems, Physical Examination, Assessment and Plan. They should also be able to show you how medical complexity and the overall score is determined from this information. The demonstration should also show how time can be used to determine the E/M coding in place of documentation when appropriate.
2. Maintain awareness of coding guidelines, i.e., do not become overly reliant on the suggested E&M code. As described below, there are certain patterns that have emerged from EHR usage that have attracted the interest of auditors. These are all readily avoided if the clinician has some very basic understanding of the coding guidelines that can be used to reaffirm or refute the accuracy of the suggested code. It is of obvious importance that the physician be allowed to override the suggested code when necessary. This gives physicians some flexibility and also accommodates different data input options such as typing/voice recognition which are often not recognized as structured data and therefore are hard to map to E&M coding data requirements.
3. Be aware of specific EHR documentation guideline related to E&M coding that need to be avoided. Some of the more common examples are provided below:
a. The Use of Default Text. EHR vendors assume when they design their applications that all the information that is included in a note has been reviewed by the clinician and is medically necessary based on the level of complexity of the encounter. In order to improve efficiency, EHRs often support the use of templates, macros, and information from a prior visit note that contains information that may or may not be accurate. Given the time pressures associated with the practice of medicine and the ease of use of default information, there is the potential for inaccurate information to be accepted in the form of encounter defaults. While this does seem like it should be a minor or exceptional issue, numerous examples of unreviewed defaults that were accepted as legitimate information have been identified by auditors. One of the more common areas where this type of behavior may occur is the review of systems (ROS). Clinicians need to carefully review the ROS to make sure that any incorrect defaults are modified, and in particular to make sure it is consistent with the HPI. For example, seeing "denies chest pain" in the ROS in a patient with a detailed description of chest pain in the HPI can lead to a negative audit. It may also be worth noting that the physician is not required to actually obtain the PFSH and/or ROS directly from the patient, as the patient or another staff member can document this information but then it must be reviewed by the clinician.
b. The Use of Default Settings. The visit type (e.g., new patient, established patient, consultation, etc.) can often be used to determine which sections of a note are populated with data automatically (e.g., Family History, Social History, etc). A not uncommon pattern is for the clinician to set the defaults to include the Family and Social history for all established visits. In general this is to be avoided. For example if the patient is seen fairly frequently there may not be any medical justification to include the social or family history with each visit. If the use of these sections increase the E/M coding level, auditors are likely to challenge this as a type of "over-coding." To avoid this relatively common pitfall, consciously determine whether or not the documented information being used to determine the E&M code was medically necessary to include in the document, based on the complexity of the presenting problems. Besides the family and social history, a full ROS (10 or more systems) or a comprehensive physical examination brought in through a template or macro may not be considered medically necessary in some settings.
c. The Use of Additional Diagnoses to Increase the Level of Complexity. One of the three components used to determine the level of complexity of the visit is the "number of diagnoses considered." However, diagnoses that are used to determine the level of complexity must meet the following criteria:
i. Code to the greatest level of specificity only: Choose only the most specific code for any given presenting problem. For example, in a patient with a firm diagnosis of cluster headache additional symptomatic diagnoses such as "headache" should not, in general, be listed as an additional diagnosis. EHR E&M coding tools will not have the level of sophistication to recognize this as a potential issue.
ii. Use only diagnoses that are relevant to the current visit: EHRs may provide the ability to easily add diagnoses (e.g., from the problem list or previously used diagnoses) to the assessment. If the condition is not relevant to the current encounter it should not be used to calculate the level of complexity of the visit.
d. Documentation Supportive of Complexity. The majority of auditors are not physicians and in some setting may have difficulty inferring complexity from the available documentation. For this reason it is advisable to add to your documentation such things as the differential diagnosis, risk associated with the natural history of the disease, and the risks associated with any proposed interventions. EHRs handle the ability to generate, store and display text of this nature in a number of different ways. However, it is advisable to avoid generating simple bulleted lists of diagnoses and treatments that are not supported by additional documentation in particular when the level of complexity is moderate or high.
In summary, the combination of a well-designed E&M coding tool and a clinician who is familiar with a few simple guidelines will result in documentation that has an extremely high level of coding accuracy. Some degree of physician oversight will always be required, but properly used EHR E&M coding software has become a fundamental audit protection tool.