Think like an Auditor for Best Practices in Documentation

Think like an Auditor for Best Practices in Documentation
Remember that if you fail an audit, it will probably be due to inadequate documentation –
regardless of whether you were actually compliant during the audited reporting period. CMS
has published a pretty good guide to assembling documentation for your Meaningful Use
attestations. It is about five pages long, and lays out a starting point. On page two, they provide
the following caveat:
“An audit may include a review of any of the documentation needed to support the
information that was entered in the attestation. The level of the audit review may
depend on a number of factors, and it is not possible to detail all supporting documents
that may be requested as part of the audit.”

So here is where we all need to start thinking like auditors. CMS clearly states that they will not
give you a comprehensive list of what an auditor could request, and puts their auditor in charge.
For the IT people who have been responsible for Meaningful Use up to this point, it might be
prudent to start having frequent lunches with an internal audit colleague. Auditors actually
think differently than IT project managers, analysts and developers, and since you can expect to
be held accountable to standards defined by a CMS auditor, it could be prudent to predict how
they may analyze your proof of compliance.
Auditors have high professional standards, and live by strict principles of diligence and
efficiency. Compensate for these audit principles the auditors follow to improve your own “body
of evidence plan”:
1. Professional Skepticism demands that a burden of proof falls on the individual or
organization being audited, and that the auditor’s personal integrity is based on
evaluating compliance based on the evidence alone.
2. Audit resources are finite and auditing must be done as efficiently as possible. If
evidence does not support a client’s assertion of compliance, the auditor is bound to
issue a statement of non-compliance if such evidence is not available.
3. Risk management drives decisions as to the amount and level of detail compliance data
needed to prove compliance. An organization with well-organized and comprehensive
data, readily provided in a timely fashion will appear less risky and will be less likely to
incur requests for additional volumes of supporting data.
4. Never subordinate your personal judgment to that of others. In the context of
Meaningful Use, this means an auditor will never assume that a large EHR vendor, or a
large Hospital or a large Clinic is likely to be “correct” just because of their size and
sophistication.
Finally, imagine what it is like to be an auditor. Every day you review the same kind of
documentation over the same kind of content, for the same kind of hospital or clinic. Conducting
audits where everything is “ok” does not raise your pulse rate. There is more excitement in

finding non-compliance, and even more in finding outright fraud. The balance of this chapter is
dedicated to sharing Meaningful Use specific principles that will make your auditor see you as
organized, knowledgeable and diligent.
If the most likely cause of an audit failure is inadequate documentation, then the best protection
you have is for Meaningful Use Administrators to have a documented process to gather data, and
a viable data maintenance plan for each year and stage of attestation, for each provider or facility
and until 2021. Once the process is built, engage your internal (or external) audit team for a
second opinion on its adequacy.
Before attesting
According to CMS, some EHR products do not provide sufficient detail reporting after the close
of your reporting period. There are best practices for documentation and data management
that your EHR vendor does not even know about, much less support. More importantly, the
ONC testing specifications for CEHRT only require creation of summary numerator and
denominator, with date ranges for each measure. There are three important elements of
documentation that an auditor may demand, for which certification requirements do not exist:
1. Patient level detail in support of the certified summary reports for numerators and
denominators. You should make sure you have reporting at detail transaction level for
each individual measure, and that your detail reports tie exactly to the summary certified
reports.
2. Yes / No Measures –there is no requirement of CEHRT to support proof of Yes/No
measures.
3. Proof of Process – every single Meaningful Use measure implies some level of clinical
or administrative process of getting data into the CEHRT. CPOE must be done by
specified personnel at a specific point in patient transactions; Vital Signs must be taken
early enough to be available during the patient visit. Much of the detail discussion in the
Federal Register associated with each measure elaborates on the theme of CEHRT as
clinical decision support enablers, rather than as a repository for “after-the-fact” clinical
data. Reporting within your EHR may not be sufficient proof; we recommend retaining
documentation of work flows, or policy statements, dated within each EHR reporting
period, and explicitly supporting the intent of each measure. Auditors (so far) seldom
request this level of information, but it could go far in showing the diligent
understanding of Meaningful Use that will impact an auditor’s decision on how deep and
wide to conduct their review of your content.
CMS's own publication states:
"Because some certified EHR systems are unable to generate reports that limit the calculation
of measures to a prior time period, CMS suggests that providers download and/or print a copy
of the report used at the time of attestation for their records."

Additionally, as you upgrade your CEHRT, you may lose previous documentation formats. The
pragmatic message is make sure you understand in detail your documentation needs and have
created all the documentation you will eventually need ... before you even attest.

With these general guidelines in mind, let’s consider some Meaningful Use specific best
practices.
Common Shortfall - ‘All Patients’ requirement
Almost every audit request results in the need for a report that almost no one expects, and
fewer prepare for in advance. And this one report could affect the denominator on six separate
requirements for your Stage 1 Providers, and almost all of Stage 2.
Here's the issue. Most of the time, CMS requires that you only count all patients whose records
are maintained in the EHR. Under Stage 1, all but six measures allowed you to calculate
denominators based on patients whose records are maintained in your Certified EHR. In Stage 2,
CMS raises the bar. All but two measures require that you include in the denominator any
patients seen by the provider, whose records are maintained outside the EHR as well.
"We don't have any of those" you say. Your problem will be in proving that statement to an
auditor, for up to six years after attestation.
The way this issue manifests as part of an audit, is in a request from Figliozzi to provide proof
that at least 80% of your patients were documented in your Certified EHR. It is not enough to
assert this ... you must provide documentation.
Remember, auditors are paid to not believe something until they see proof. Best Practice is to
create a report from a separate billing or practice management or census reporting - anything that
would be credible to a skeptic. Be sure to document any reconciliation between the billing report
listing of Unique Patients, and the EHR number of Unique Patients. Both reports should be
against the same reporting period. Save that report to a PDF, and store it with your permanent
Meaningful Use documentation.
Compare this total to the total unique patients in your EHR before you attest. If the billing

report shows a greater number of patients than what are in your EHR, you must include the
difference in the denominators of the six measures requiring ‘All Patients’ in the
denominator. And because two of those measures have a threshold of 80%, your ratio could be
very sensitive to additions.
One last thing. If your All Patients proof shows more patients that what are in your EHR, you'll
need to be sure to add those extra patients into the appropriate denominators when you attest. It
will adversely impact your meaningful use ratios, but better to know that in advance of an
auditor asking.

Don’t lose the Logo
That little EHR Vendor logo on your Meaningful Use Reports is not just vendor marketing – it is
a compliance documentation tool. Put yourself in the shoes of a skeptical auditor for a

moment. A provider gives you a report that he says supports his Meaningful Use
attestation. But how do you know it was not just a Word Document someone created with the
right answer?
This is the kind of situation auditors are hired to find, actually. And they expect to see it. So
give yourself and them a break, and save the reports from your EHR that contain the EHR logo if
it is available.
If the Logo is not there, keep the parts of header / footer showing the EHR Vendor name and
software version. Of course you can't include what does not exist. So if your reports don't have
vendor information explicitly attached, you'll have to supplement. Here are some good options:
Minimal requirements – in the header and/or footer of any report used for audit proof,
include the name of the clinic or hospital, name of the EHR, and the CHPL number used
when you attest.
Detail process description with screen shots - For any report lacking vendor-provided
identification, you should assemble a word or power point document showing screen
shots and instructions from the EHR showing how the report was generated, parameters,
user name of the person running the report, or anything that would help to show the
source of the report.
If no screen shots – scan sections from vendor's instruction manual, and/or your own text
on how you generated the report.
It is not required that Meaningful Use Reports come from your EHR, but the auditors will want
to know that the Data is from the EHR. Keep this in mind as you create your documentation.
Keeping Yes and No Safe
Seems simple, yes? Yes / no measures are the most sensitive to inadequate
documentation. Your EHR gives reports on all the numerator / denominator measures, because
the regulators verify that it can do so before certifying. But remember that there is no
requirement for certifying that the EHR be able to prove that a yes / no measures were active
during the reporting period. This is always your responsibility, and an easy one to overlook.
Some yes / no measures recommend that you take a screen print, during the reporting period.
Each screen print should clearly show the EHR name or logo, the provider name, and the date it
was snapped. For example, a screen print of your EHR showing "Drug Formulary" interaction is
turned on now, does not prove to an auditor that it was turned on during your 2012 reporting
period. And auditors will not assume that simply because the EHR can do Drug Formulary
reporting, that you had it active during your reporting period.
Other Yes / No measures are completely outside the ability of your EHR to know or prove the
answer. Connecting with public health or conducting a Security Risk Assessment are two great
examples. If your State sent you an email or letter documenting your compliance, take a screen
shot or scan into a PDF format and attach to your documentation.

The important point is that every single requirement demands documentation, and every single
piece of documentation must be identified as to provider, EHR, and attestation period.
Detail Patient Logs
This is a hard topic, first because it could require a lot of extra work of your report writing team your EHR is not required to provide them (in order to be certified). Next, not every audit will
ask for detail patient logs, so it is a little “roll of the dice”. The problem is that because audits
are always after the end of the reporting period – perhaps after several years and EHR versions
have passed – you may not be able to reproduce the data as it was when you attested. So you
have to make a decision now, to spend scarce resources on an event that may not occur.
What that means, is that strict safety requires that you create a series of reports that match up to
the summary-level reports your EHR creates. Then be sure to run those detail patient logs for
each measure, for each provider, for each reporting period. And you'll probably want to do it at
the end of the reporting period, before the underlying data changes is a fashion that prevents
you from duplicating your attestation summaries. Run these reports to PDF and save them
electronically ... that is the way CMS will ask for them in event of an audit.
Of course, creating and analyzing these reports serves another valuable meaningful use
function. You may have noticed the paragraph on the CMS attestation site claiming that
‘completeness and accuracy of attested data is the responsibility of the provider’. What this
means, is that if your EHR vendor's summary report contains an error, CMS will hold you
responsible for complete and accurate attestation. They won't let you off the hook if an
erroneous report causes you to attest incorrectly.
Running and analyzing patient level reports is your best defense against ‘completeness and
accuracy’, as well as preparing for an auditor wanting to conduct a deep dive against this year's
attestation, six years down the road.
When you construct your detail patient logs, consider how an auditor could use them to validate
your summary reports, by looking at patient level transactions for each Measure. One good
practice is for each selection criteria, organize the data into “compliant” and “non-compliant”
subtotals. The grand total should support your denominator. The “compliant” total should
support the numerator, and “non-compliant” should be everyone else.
An auditor will validate the counts in each subtotal by sampling several pages, counting the
average number of transactions per page, and extrapolating to subtotals. If your PDF is
organized in a fashion that lends itself to conversion to spreadsheets, try to set up the data with
one “row” per transaction. That way your auditor (or you, in your own validation efforts) can
use spreadsheet tools to count transactions in each category.
Policy and Procedure Documentation
For each appropriate measure, there needs to be a Policy or workflow document stating how the
measure is documented at your facility. For example, with CPOE the document should

demonstrate that CPOE was done “in a sufficiently timely fashion that the EP could react to any
alerts generated by the order” and show that only “licensed healthcare professionals (based on
state, local or other professional guidelines)” can enter orders into the electronic chart. Note that
to be acceptable as audit evidence, the policy or workflow should be identified as being effective
during the reporting period.
If you use the technique of Mock Audit (described later in this report), your Mock Auditors
should be familiar with the Meaningful Use regulations as they read the policy or workflow
documentation provided by your Meaningful Use Administrator. A common shortfall in these
documents is a failure to clearly state that content must be represented in the CEHRT. The
policy / workflow statement, in order to be useful for Meaningful Use, should also be sure to
reflect all data elements and processes specifically required by the individual Meaningful Use
requirement it supports. In our experience, documentation created for Joint Commission, clinical
standards or other compliance domains tends to be very close to Meaningful Use, but generally
misses at least some points.
It could be a good practice to assemble and review your clinical policy and workflow documents
to see the degree to which they provide evidence of compliance with Meaningful Use details.
Get the Timing Right
When should MU Coordinators generate reports for a given Reporting Period? A common
question of our Meaningful Use Help Desk receives is about what should be created, at what
points in time, throughout the reporting period, to prepare and assemble the appropriate
documentation for Meaningful Use. It is an excellent idea to organize your Meaningful Use
Measures based on what documentation must be developed within the reporting period (e.g.,
Security Risk Assessment, screenshots showing that a capability is enabled), what
documentation should be immediately at the close of the period (numerator / denominator
reports), and which could possibly be deferred until after attestation.
In any of the yes/no measures requiring proof that a capability is turned on (i.e., drug formulary
interaction), capture a screen shot at the beginning of the period, and again at the end. Be sure
that the screen shot shows hospital / clinic identification, and the EHR vendor (version would be
good if possible), and the date of the screen shot. It might take a little work composing the
screen to show all that, but if your documentation is missing any of these key element, you've
wasted your time.
The security risk assessment should be completed during the fiscal year of each annual
attestation.
Numerator / denominator reports need not be saved to PDF until the end of the overall
reporting period, but a best practice along the way is to analyze your certified EHR summaries at
least monthly, just to see how you are doing. Last year's compliance is no guarantee that
everyone will sustain it through this year. If you have Meaningful Use Monitor, that tool will
help make sure you are looking at all the measures; if you don’t have Meaningful Use Monitor in
place yet, build your own database that lists every single item (including all yes/no measures and

CQM’s), so that you don’t miss something that the EHR does not track (i.e., public health
connectivity or SRA, or CDS rule).
Also start developing a parallel report from your billing system that will calculate total unique
patients over the same reporting period to which you’ll be attesting. Remember that there are
several measures requiring you to incorporate any “non-EHR patients” into the denominator
across all of POS 21 and POS 23 for hospital, and for each EP individually in the ambulatory
world. It is best to know about those non-EHR patients, and incorporate them into your ongoing
metrics. When you get audited, CMS will ask for proof of this analysis, even if only to prove
that you have zero patients outside your EHR. It is always easier to synch up data across
multiple systems concurrently, rather than trying to do it a year or more after the fact, when an
audit occurs.
Finally, you should start creating detail patient reports for each measure. Use these detail reports
to validate the certified numerators and denominators reports from your EHR, each time you
analyze your summary reports. Even though CMS certifies the EHR to generate these reports,
they do not deploy sufficient test data to verify the reports are accurate under all circumstances,
and doing so is clearly the responsibility of the provider. Auditors will often (but not always)
request these reports, and it is easiest to make sure the summary (certified) and detail
(customized) reports match, when done concurrently with the reporting period. This is a best
practice for all IT work, of course … not just for Meaningful Use. After all, how do you go
about deciding whether any summary statistics are correct?