Appendix C: Steps to Prevent Fraud in EHR Documentation
Preventing fraud due to the deliberate falsification of information when electronic health records (EHRs) are used requires three primary conditions:
- Organizational desire and commitment to conduct business and provide care in an ethical manner.
- Organizational purchasing systems that include the functions and capabilities to prevent or discourage fraudulent activities.
- Organizational implementation and use of policies, procedures, system functions, and capabilities to prevent fraud.
The following guidelines provide recommendations for organizations to reduce the likelihood of fraud when EHRs are being used.
Steps Organizations Can Take to Prevent Falsification of EHRs
1) Organizations must establish organization-wide policies.
a) An organization communicates its ethics and commitment to complying with laws and regulations through its policies. Organization-wide policies that should be established to reduce the likelihood of fraud include those:
i) Indicating the organization’s commitment to complying with all laws and regulatory requirements and to operating in an ethical manner.
ii) Prohibiting the entry of false information into any of the organization’s records.
iii) Defining individual responsibility and accountability for the accuracy and integrity of information and for notifying management of errors that are discovered.
iv) Specifying consequences for the falsification of information.
v) Requiring periodic training covering the falsification of information and information security.
vi) Defining management-level responsibility for the organization’s information security program.
b) Organizations should also establish EHR- and HIM-related policies:
i) Specifying administrative documentation requirements.
ii) Specifying clinical documentation requirements.
iii) Requiring the logging of activity on EHR systems.
iv) Covering changes (i.e., corrections and amendments) to records.
This is the list of highly recommended policies and is not meant to be exhaustive. Organizations implementing an EHR may need to develop additional policies according to their needs.
2) Organizations should establish and maintain an education program. The education program must be designed to communicate the organization’s policies, the individual’s responsibilities, and the capabilities and functions of the EHR system to each individual who works with EHRs.
The objectives of this recommended education program are to:
a) Inform all individuals associated with the organization of the organization’s policies.
b) Explain responsibilities for maintaining the integrity and accuracy of information:
i) Personal responsibility for protecting system access information
ii) Personal responsibility for creating accurate records
iii) Responsibility to notify management of problems that are discovered
c) Cover the proper use, features, and functions of the EHR system.
d) Address methods for preventing erroneous entry of information and the importance of preventing errors.
e) Cover penalties for falsifying any organizational records.
f) Provide instruction on how to use the system security features to prevent unauthorized access to systems.
g) Inform all EHR users that their activities are being logged by the system.
h) Address social engineering or other techniques that may cause system users to enter false information. Social engineering refers to the duplication or manipulation of gullible or well-meaning system users to convince them to take some illegal or unauthorized action to enter information into a system, divulge a password, or take some action to harm the system.
Refer to Section A on fraud prevention education programs for specific recommendations for designing and offering education programs.
3) Organizations must establish a process for logging of all activity on EHR systems.
a) Determine which logging features should be used.
b) Enable system logging.
c) Assign responsibility for auditing of log entries and reported exceptions.
d) Define retention periods and procedures for log records.
Refer to Section B on logging of activity in EHR systems for specific recommendations regarding documentation falsification and logging.
4) Organizations must define and implement the business rules relevant to the responsibility of each functional role and each type of information. Refer to Section C on sample business rules for a partial example.
Guidelines for Selecting EHR Systems to Reduce the Likelihood of Falsification
Consider EHR systems with the following capabilities:
1) Access control functions:
a) User authentication
b) Extensive privilege assignment and control features
2) Capability to attribute the entry, modification, or deletion of information to a specific individual or subsystem.
3) Capability to log all activity. Refer to Section B on logging of activity in EHR systems for specific logging requirements.
4) Capability to synchronize a common date and time across all components of the system.
5) Data entry editing:
a) Verify validity of information on entry when possible
b) Check for duplication and conflicts
c) Control and limit automatic creation of information
Refer to Section D on selecting EHR systems for more details.
Section A: Fraud Prevention Education Programs
Education programs need to address the different functionality of an electronic versus a paper environment specifically for individuals who have previously worked in a paper health record environment. EHR users will more than likely continue to use paper records along with the EHR, so distinctions regarding the unique fraud risks of the EHR must be conveyed. In the paper environment, data are usually static, and alterations or changes to documents are more readily apparent. In the EHR, alterations can more easily go undetected, and errors can grow exponentially. EHR fraud prevention education programs should address:
1) Training Requirements:
a) Annual education and training: The organization is responsible for ensuring that EHR users receive regularly scheduled education and training on the organization’s policies and procedures for maintaining EHR integrity including security and log in, validity of data, authorship/authentication, use and storage of data, and data transmittals. This training should be updated annually and can be incorporated as a separate focus area into the organization’s compliance and HIPAA training.
b) Documentation of education activity: Education programs are to be documented and become a part of the physician, provider, or employee’s permanent medical staff or human resource record. In the event of any possible future issues regarding false or fraudulent entries, the organization will be able to demonstrate that due diligence was exercised in the training of its staff.
c) Mandatory requirement: All users must complete the education program.
d) Documentation guidelines: The education program needs to clarify and reinforce that the HIM documentation requirements and documentation guidelines accepted and established for the paper record also apply to the EHR. In addition, all regulatory and oversight agency requirements for documentation, such as for the Centers for Medicare and Medicaid Services (CMS), the Joint Commission on Accreditation of Healthcare Organizations (JCAHO), the Accreditation Association for Ambulatory Health Care (AAAHC), and the American Osteopathic Association (AOA) apply to the EHR as well.
2) Security and Integrity Requirements:
a) Personal responsibility for protecting system access: All EHR users must protect their log-in or sign-in from unauthorized access. The user is prohibited from sharing individual security information with others and must report breaches of login or sign-in security immediately. EHR users must secure their desktops and laptops or other data access devices whenever they are away from them.
b) Personal responsibility for notifying management of actual or suspected problems: EHR users are not to hesitate in notifying management of problems even if a problem is only suspected and cannot be confirmed by the EHR user. These problems may be security breaches, suspicious activity or uncharacteristic data entries, unauthorized access, data entry errors that the user is unable to correct, amendments to data that are not in line with the organization’s policies and procedures for amendments, or any other activity not in accordance with the organization’s policies and procedures.
c) Personal responsibility for creating accurate records: It is particularly important to verify the patient record selected on an EHR because, unlike the paper record, once the patient is selected, the EHR screen flows may not alert the user to the patient’s identification. Furthermore, the paper record is three-dimensional and has many labels and visual prompts at the fingertips, whereas patient identification on an EHR may not be prominently displayed. Education should be directed to training EHR users to verify routinely a minimum of two or three unique patient identifiers such as name, date of birth, and account number.
The EHR users are responsible for each element of data they enter into the record and must provide electronic verification of authorship/authentication, which includes data that have been copied and pasted or pulled forward from other parts of the patient’s record or from sources outside of the patient’s record. Each entry that is not solely authored by the user must be validated by the user in a manner similar to that for bibliographic notations and include the name, date, and source of the data. This requirement can be satisfied by system software design that routinely provides this validation.
d) Logging, time stamping, and fraud-prevention software: The education sessions should explain that routine security programs are run on a regular basis and reviewed for unusual or invalid activity. As a deterrent to fraudulent activity, if the organization uses fraud prevention software, a general explanation of its purpose could be discussed.
3) Violations of EHR Policies and Procedures:
Educational programs need to address clearly the organization’s disciplinary and termination policies governing falsification of records, security and access breaches, or violations. The education program should also refer to the organization’s policy for HIPAA and note should be made that EHR security is in line with protection and security of health information. Further reference should be made to various federal and state legislation and the requirements of various oversight agencies:
a) Federal False Claims Act
c) Deficit Reduction Act of 2005
d) Department of Health and Human Services Office of Inspector General (OIG) Guidance for Hospitals and Physicians
e) CMS Conditions of Participation
f) JCAHO Accreditation Requirements
g) AOA Accreditation Requirements
h) AAAHC Accreditation Requirements
i) Medical Staff Bylaws of the Organization
Please note that the program and content outlined above are recommended as a starting point for organizations. Modifications and additions should be made as appropriate to meet organizational needs.
Section B: Establishing a Process for Logging Activity in EHR Systems
An audit trail is a business record of all transactions and activities, including access, that are associated with the EHR. Monitoring audit trails in your system will ensure that users can be held accountable for following the organization’s policies and procedures, adhering to compliance rules and regulations, and following HIM protocols for access and maintenance.
Facilities using electronic health information systems need to ensure that individuals entering information into the EHR are aware that system audit trail functionality is in place allowing them to legally access, amend, retract, correct, or edit entries that were made during the normal course of business, at or near the time the care.
1) Determine Which Logging Features Should Be Used and Determine System Logging Capabilities:
a) The system should be able to generate an audit record when auditable events happen, including but not limited to the following (success, attempt, and failure):
i) User login/logout
ii) Chart created, viewed, updated, or deleted
iii) System security administration
iv) System start and stop
viii) Node-authentication failure
ix) Signature created or validated
x) Personal health information (PHI) export (e.g., print)
xi) PHI import (e.g., from external information source)
xii) System administration
b) The system should record within each audit record the following information when it is available:
i) Date and time of the event.
ii) Component of the information system (e.g., software component, hardware component) where the event occurred.
iii) Type of event (including data description and patient identifier when relevant).
iv) Subject identity (e.g., user identity).
v) Outcome (success or failure) of the event.
c) The system should provide authorized administrators with the capability to read all audit information from audit records in one of the following two ways:
i) The system should provide the audit records in a manner suitable for the user to interpret the information. The system should provide the capability to generate reports on the basis of ranges of system date and time that audit records were collected.
ii) The system should be able to export logs into text format and correlate records on the basis of time (e.g., universal coordinated time [UTC] synchronization).
d) The system should be able to provide time synchronization by using an industry standard format and use this synchronized time in all security records of time.
e) The system should record time stamps by using UTC on the basis of ISO 8601-2000 (e.g., “1994-11-05T08:15:30-05:00” corresponds to November 5, 1994, 8:15 a.m., US Eastern Standard Time).
f) The system should prohibit all users read access to the audit records, except users who have been granted explicit read-access. The system should protect the stored audit records from unauthorized deletion. The system should be able to prevent modifications to the audit records.
g) The system should continue normal operation even when the security audit facility is nonfunctional. For example, if the audit log reaches capacity, the system should continue to operate; issue a warning to system administrators; and suspend logging, start a new log, or begin overwriting the existing log.
Note: This section is adapted from the Certification Commission for Healthcare Information Technology Test Scripts for 2006 Certification of Ambulatory EHRs, Version 1.0, May 2006 at http://www.cchit.org/work/criteria.htm.
2) Assign Responsibility for Auditing of Log Entries and Reported Exceptions:
a) Leadership and management are ultimately responsible for developing policies and procedures that spell out and assign responsibility to professional and ancillary leadership staff to determine system functionality, system security, and system usability as well as report any system inefficiencies or discrepancies potentially resulting in fraudulent entries into the EHR.
b) Leadership and management should always adhere to legal and regulatory standards and follow ethical business principles when auditing the system for integrity and trustworthiness of the data.
c) The system should allow an authorized administrator to set the inclusion or exclusion of audited events on the basis of organizational policy and operating requirements and limits.
3) Define Retention Periods and Procedures for Log Records:
a) The system should generate a backup copy of the application data, security credentials, and log and audit files.
b) The system restore functionality should result in a fully operational and secure state, which should include the restoration of the application data, security credentials, and log and audit files to their previous state.
c) If the system claims to be available 24/7, it should have the ability to run a backup concurrently with the operation of the application.
d) The audit report must include a copy of the output of the audit as well as the steps taken to produce the report.
e) Retention of audit logs is based on state and/or federal laws, whichever applies to the organization. Please see AHIMA practice briefs “Update: Maintaining a Legally Sound Health Record—Paper and Electronic” from November-December 2005 and “New Electronic Discovery Civil Rule” from September 2006.
4) Areas Recommended for Monitoring or Auditing for Detecting Alleged Fraud and Abuse Related to EHR Documentation:
Note: There are reasons other than documentation and fraud and abuse concerns that would encourage monitoring and auditing. Each organization must determine which monitors and audits are appropriate to address the requirements of applicable laws, regulations, needs, and available resources. Each organization is also responsible for specifying the method for determining whether the activity is legitimate or suspect and any necessary consequences.
a) Abnormal patterns of activity:
i) Spike in the number of people accessing a particular record or document.
ii) Sudden variation in the magnitude or types of changes made in a record.
iii) Unusual repetition of particular entries in a record.
iv) Entries or other transactions occurring at unusual times of the day or days of the week.
b) Routine documentation monitoring:
i) Review of problem lists and medication lists against prior lists for consistency.
ii) Audit providers’ orders for medications and ancillary services to determine if a provider properly documented the reason(s)/diagnosis(es) for the test(s)/medication(s) ordered.
iii) Audit to determine whether transcription/dictation reports are downloaded to and appear in the correct patient and correct visit date fields.
c) Routine coding monitoring and auditing:
i) Monitoring the computerized assignment of codes according to applicable coding system guidelines.
ii) Ensuring the documentation supports the code assigned.
iii) Noting unusual changes in the frequency of use of certain types of codes, etc.
d) Auditing of EHR access and documentation to ensure users are authorized according to privileges and business rules.
e) System-generated warning messages related to attempted unauthorized access.
f) Monitor software upgrades and system changes to verify that security settings, user privilege settings, and logging parameters were not disabled or modified as a result of the upgrade or change.
5) Possible Techniques for Auditing or Monitoring:
a) Standard sampling techniques backed by rigorous claims audits involving external validation procedures.
b) Use test vignettes to evaluate the legal record for amendments, attestation, authorship, integrity, and nonrepudiation.
6) System Audit Trails:
The HIPAA Title II security rule CFR Part 136.316(b)(1) (taken from the February 20, 2003, Federal Register, page 8368) is the source for this paragraph. It mandates audit trails be maintained within the EHR. Internal audit processes must be in place, and regular system activity reviews must be completed for logins and accessing files. Security incidents must be monitored and resolved.
Keep in mind that logging and auditing processes may affect the performance of a system, and an organization may need to purchase additional hardware, memory upgrades, and/or bandwidth to support these audit requirements. Audit data must continuously be reviewed and analyzed, processes that may also require additional resources.
Section C: Sample Business Rules for EHR Systems
Establishing business rules is very similar to the process historically occurring in the medical record committee. Business rules designate who can document what in the record and how the documents are to be handled.
This business rule presented here should not be considered a complete business rule, nor does it represent all of the business rules needed for an EHR system. Business rules are specific to an organization and its EHR system configuration.
Business rules authorize specific users or groups of users to perform specified actions on documents in particular statuses.
< A completed clinical document can be viewed by a user.
< An unsigned clinical document can be edited by a provider who is also the expected signer of the note.
< An unsigned clinical document can be deleted by the appropriately authorized personnel.
Business rules apply to document definition, user class, or user role. You can then add, edit, or delete rules, as appropriate.
1) Document Definition:
2) List Business Rules by Document for Clinical Documents:
- An untranscribed clinical document may be entered by a user.
- An unreleased clinical document may be released by a transcriber.
- An unsigned clinical document may be edited by an author/dictator.
- An unsigned clinical document may be edited by an expected signer.
- An unsigned clinical document may be signed by an expected signer.
- An unsigned clinical document may be signed by a provider who is also an expected cosigner.
- An unreleased clinical document may be edited by a transcriber.
- An uncosigned clinical document may be cosigned by an expected cosigner.
- An unsigned clinical document may be signed by a student who is also an expected signer.
- An unsigned clinical document may be edited by an expected cosigner.
- An untranscribed clinical document may be entered by a nurse.
- An uncosigned clinical document may be sent back by a provider who is also an expected cosigner.
- An amended nurse's note may be edited by a nurse or an author/dictator.
- An amended nurse's note may be edited by a nursing supervisor or an author/dictator.
3) Status of Business Rules: Actions Permitted for a Given Document Definition and Status:
- The document has been completed, and a HIPAA
issue has required its amendment.
- The document has acquired all necessary signatures
and is legally authenticated.
- The document has been deleted but the audit trail is
- This status applies to document definitions only.
- The grace period for purge has expired and the report
text has been removed from the online record to recover
disk space. Note: only completed documents can be
purged. The chart copy of the document should be
retained for archival purposes.
- The document is complete, with the exception of
cosignature by the attending physician.
- The document is required and a record has been created
in anticipation of dictation and transcription, but the
system hasn’t been informed of its dictation.
- The document is in the process of being entered into the
system but hasn’t been released by the originator (i.e.,
the person who entered the text online).
- The document is online in a draft state, but the author’s
signature hasn’t yet been obtained.
- The document is required, and the system has been
informed of its dictation, but the transcription hasn’t
yet been entered or uploaded.
- The document has been released or uploaded,
but an intervening verification step must be completed
before the document is displayed.
Business rules are complex, and there are additional rules for inheritance of business rules, inheritance along the document definition line, overriding business rule inheritance, inheritance along the user class line, and inheritance and addenda, etc.
Section D: Selecting EHR System Features to Prevent Fraud
Organizations should consider selecting EHR systems with the following capabilities:
1) Access Control:
Verifying authorship hinges on two concepts: authentication and access management. In the simplest terms, identity and access management can be defined as an integrated system of business processes, policies, and technologies that enable organizations to facilitate and control their users’ access to critical electronic applications and resources while protecting confidential personal and business information from unauthorized users. Authentication and access management can be executed either through the EHR software, or it can be controlled through a separate, or layered, software application.
a) User authentication:
Authentication is the process of determining whether someone or something is, in fact, who or what it is declared to be. The purpose of authentication is to show authorship and assign responsibility for an act, event, condition, opinion, or diagnosis. Entries in the healthcare record should be authenticated by the author.1 The method of authentication should be considered in selecting an EHR system.
1) Three basic elements can be used for authentication:
a) Something the user is such as some form of biometric identifier (e.g., fingerprint or retinal pattern, DNA sequence voice pattern, signature recognition).
b) Something the user has such as an identification card, security token, or software token.
c) Something the user knows such as a password or a personal identification number (PIN).
2) If biometric authentication is not available, then a dual-element authentication should be considered as a reasonable control policy.
b) Extensive privilege assignment and control features:
Access management, also known as authorization, is the process of verifying that a known person has the authority to perform a certain operation. Verification of the identity of a user or other entity is a prerequisite to allowing access to information systems.2 When an organization selects an EHR system, the organization should be able to control access through role-based descriptors and individual identification and the ability to configure multiple access management levels.
2) Logging of All Activity:
The ability of the organization to maintain a legal medical record in the electronic environment is a paramount consideration in the selection and use of an EHR system. The EHR must have the ability to record all activity that occurs within the system. (See Section B.) A good EHR system must include a robust and complete logging and auditing function.
3) Data Entry Editing:
a) Verify validity of information on entry when possible:
The ability of the system to either warn or not allow impossible information, such as a hysterectomy CPT code for a male patient or a prostate examination for a female. These systems can be more sophisticated to not allow or at least prompt or warn the user of less likely events or occurrences, including using billing codes that do not meet the medical necessity criteria for payers.
b) Check for duplication and conflicts:
The system that will not allow duplication of patient identification numbers or codes and one that will warn of conflicting medical management options, such as life-threatening drug interactions may be useful. The ability of a system’s prompt capability should be thoroughly explored by the clinical users because there is emerging evidence of a phenomenon known as “prompt fatigue.” A system without the ability to control the prompt occurrence can lead to lack of use or even misuse by the providers entering information.
c) Control and limit automatic creation of information:
The ability to create documentation automatically, whether through a copy-and-paste or pull-forward function, selection of generic documentation, or use of “auto-neg” or other documentation by exception functions should be avoided. In most circumstances, such features should be disabled. These features, although they are time-savers, are dangerous to the organization and the individual practitioner because they foster the ability to commit fraud, intentionally or unintentionally. They are also a source of “dirty data” that will compromise good patient care and data-mining capabilities.
d) Monitor corrections and additions to the medical record:
Corrections, amendments, clarifications, and additions to a medical record are a normal part of clinical documentation. These changes to the EHR should always be made available to the user of the record unless such changes are detrimental (e.g., incorrect information was originally recorded about the patient). The EHR should have the ability to handle these events easily and thoroughly, and of most importance, properly, as outlined in CMS guidelines; federal, state, and local laws; and hospital bylaws and accreditation standards.
These features are not intended to be a complete list of necessary or desired EHR system capabilities. Their inclusion in an EHR system will assist in preventing the potential for falsifying documentation in the patient record.
1. AHIMA e-HIM Work Group on Maintaining the Legal EHR. "Update: Maintaining a Legally Sound Health Record—Paper and Electronic." Journal of AHIMA 76, no. 10 (2005): 64A–L.
2. Amatayakul, M., S.S. Lazarus, T. Walsh, and C. Hartley. 2004. Handbook for HIPAA Security Implementation. Chicago, IL: AMA Press.