Tracking process results, at the granularity level of a requirement, is what drives HIPAA documentation as we will discuss in this article. Sure, you will have to develop policies and document your processes but this documentation pales in comparison to tracking process results. The rest of this article will discuss the kind of process results you should be tracking on a rule by rule basis.
The Privacy Rule
The Privacy Rule ("PR") has many more documentation requirements than are apparent on its face. The reason for the "hidden" documentation requirements is the fact that the Privacy Rule, by and large, has not been fully implemented in most organizations (i.e. not including the Notice of Privacy Practices or "NOPP"). The list below assumes that you have a global Privacy Rule Policy in place (e.g. covering basis policy such as the "Minimum Necessary" principle.
§ 164.502. This section contains the general rules regarding permitted Uses and Disclosures and represents the starting point for determining whether or not the PR has been violated. You need a documented process for determining when the PR has been violated for at least the following two reasons: (1) sanctioning employees; and (2) determining if breach notification has been triggered.
§ 164.502 (g). You need to have post Omnibus Rule Business Associate Agreements (BAA) in place. Any
created and executed before that time are obsolete.
§ 164.502 (g) § 164.502 (f). Determining who qualifies as a personal representative is a complex
state law issue. You should have a decision tree in place for every state in which you operate
so that counsel need not be called every time this issue comes up.
§ 164.508. Authorizations. You need a document that logs authorization on a per patient basis and
also tracks when PHI may have been shared based on an Authorization.
§ 164.512. Public Policy. You should maintain a log of when disclosures of PHI were made for
public policy reasons. All of the PR logs will prove useful when (not if) you are asked to do an
accounting for disclosures of ePHI.
§ 164.514. De-identification. You need a de-identification log to track what deidentified data was
shared, who it was shared with, and how (and by whom) the de-identification was conducted.
§ 164.520. Notice of Privacy Practices ("NOPP"). The Omnibus Rule mandated revisions to your exising
NOPP. Therefore, if you have not updated your NOPP since then your current version is obsolete.
§ 164.522(a). Restriction Requests. You need to have a log of which Restrictions (i.e. on PHI) have
been requested by patients. There is only one Restriction that you currently have to honor and that
is the "paid for out-of-pocket" Restriction. However, you have to have a process in place that allows
patients to request Restrictions.
§ 164.522(b). Confidential Communications. You need to have a log in place that allows patients to
make requests for alternative Confidential Communication methods. Further, if the Confidential
Communication request is "reasonable" then you have to honor it.
§ 164.524(a). PHI Access Requests. You need to have a log that tracks PHI Access requests. You also
need to respond to said requests in the timeframe specified by the rule. If you can't respond in the
required timeframe you must request an extension from the patient in writing.
§ 164.526(a). PHI Amendment Requests. You need to have a log that tracks PHI Amendment requests. You
also need to respond to said request in the timeframe specified by the rule. If you can't respond
in the required timeframe your must request an extension from the patient in writing.
§ 164.528(a). Disclosoure Requests. You need to have a log that tracks PHI Dislsoure requests. You
also need to respond to said requests in the timeframe specified by the rule. If you can't respond
in the required timeframe you must request an extension from the patient in writing.
The Security Rule
§164.308(a)(1)(ii)(A). Risk Assessment. You have to gather the following data that creates, updates or maintains ePHI: (1) inventory of your devices (PCs, Servers, Phones, Pads, Routers, etc.); inventory of databases; inventory of networks; inventory of business processes, etc. (2) Threats; (3) Vulnerabilities; (4) Security Controls; (5) Risks; and (6) final Risk Assessment documentation (e.g. what Risks were identified and which controls were implemented to reduce said risks).
§164.308(a)(ii)(B). Risk Management. This Standard requires you to produce documentation for every implementation specification contained within the Security Rule ("SR"). This documentation must specify the action you took for each specification whether "Addressable" or "Required." Moreover the Risk Management Standard essentially represents the entirety of your compliance program. Therefore you need standardized reporting that captures the effectiveness of your program over time.
§164.308(a)(ii)(C). Sanctions. You must have documentation each time you Sanction a Workforce member for a violaiton of the SR.
§164.308(a)(ii)(D). Information System Review. You must be able to produce documentation demonstrating that specific members of your Workforce are reviewing audit logs (e.g. application, database, network) from inventory items that have an impact on ePHI.
§164.308(a)(2). Assigned Security Responsibility. You must have documentation showing that there is a member of the Workforce that has been assigned the role of Security Officer. This job responsibility should appear in the individual's personnel file.
§164.308(a)(3)(ii)(A). Authorization and Supervision. You must produce documentation showing there is a chain of command responsible for determining which Workforce members gets access to what ePHI.
§164.308(a)(3)(ii)(B). Workforce Clearance. You must produce documentation showing how Workforce members are "cleared" during the hiring process and subsequent to it (e.g. documentation regarding checks for credit history , criminal records, etc.). This documentation must be kept in the individual's personnel file.
§164.308(a)(3)(ii)(C). Termination Procedures. You must produce documentation that showing security that Security clearance allowing access to ePHI is promptly and correctly removed once a Workforce member is terminated. This documentation encompasses the process that the Organization follows upon termination.
§164.308(a)(4)(ii)(B). Access Authorization. You must document your method for restricting Access to ePHI to your Workforce, and to outside stakeholders, where appropriate (e.g. business partners, patients, etc.).
§164.308(a)(5)(ii)(A). Security Reminders. You are required to document the Security Reminders you send as required by the SR. Generally, if these are done via email then a history of the emails sent should suffice as the requisite documentation.
§164.308(a)(5)(ii)(B). Protection Against Malicious Software. You need to document the strategy and methods that you have implemented to guard against malicious software (e.g. which virus protection programs are used within your organization and what kind of coverage is provided).
§164.308(a)(5)(ii)(C). Login Monitoring. You need to document how your organization tracks failed login attempts. Such tracking often provides clues as to persons or electronic agents wrongfully attempting to gain access to your ePHI.
§164.308(a)(5)(ii)(D) Password Management. You need to document your organization's strategy and methods for managing with passwords. For example, do you require "strong" passwords? How often are users required to change passwords, etc.
§164.308(a)(6)(ii). Security Incidents. You must document the strategy and methods used to respond to Security Incidents, including but not limited to the following: (1) who is the named Workforce member or group responsible for collecting and analyzing incidents; (2) how are incidents tracked and recorded; (3) who decides whether or not an incident should be escalated; and (4) what the organization's methodology is for determining if there has been a breach; etc.
§164.308(a)(7)(ii)(A). Data Backup Plan. You are required to document strategy and methods used for taking backups, including but not limited to the following: (1) are incremental backups taken daily; (2) how often are full backups taken; (3) who is responsible for ensuring that backups actually performed their intended task (i.e. are not corrupted); (4) what is your offsite storage strategy; and (5) what is your cloud strategy.
§164.308(a)(7)(ii)(B). Disaster Recovery. You are required to have a documented Disaster Recovery Plan. You must also document your plan's test results and how often testing occurs.
§164.308(a)(7)(ii)(C). Emergency Mode Plan. Your Organization is required to develop and implement an "emergency mode" operational plan. Emergency mode operation involves only those critical business processes that must be in place in order to protect the security and availability of ePHI during, and immediately after, an emergency.
§164.308(a)(7)(ii)(E). Applications and Data Criticality. Your Organization is required to assign a "criticality indicator" to its Information Systems (and data) and document same in order to facilitate a determination as to the "prioritized list" of systems that should be re-instantiated in the event of an emergency and/or a disaster.
§164.312(a)(2)(i). Unique Identification. An Organization is required to uniquely identify its Workforce members, business associates, and third party Information Systems when it grants access to its ePHI. These unique identifiers should be documented in the most relevant application or enterprise system.
§164.312(a)(2)(ii) Emergency Access Procedure. An Organization is required to provide access to Information Systems and computing infrastructure during an emergency. The strategy and methods by which this access is provided should be documented.
§164.312(a)(2)(ii) Automatic Logoff.An Organization is required to provide "automatic logoff" functionality in its Information Systems and computing infrastructure. This functionality must be provided for Information Systems, networks, and devices. In short, automatic logoff functionality is a best practice for preventing unauthorized access to ePHI. You should document which systems, networks and devices have this functionality in place. It is useful information to have in place when conducting a Risk Assessment.
§164.312(a)(2)(ii). Encryption and Decryption. Encryption is an industry best practice but is only "Addressable" under the SR. Therefore, it turns out you can be in compliance with SR without using encryption. That said, encryption is mandatory if you want to take advantage of the Breach Notification safe harbor. You should document all systems and devices where encryption is enabled.
§164.312(b). Audit Controls. An Organization is required to instrument its Information Systems and computing infrastructure with mechanisms that allow for recording and examining ePHI usage at the level of the individual. This Standard has an "implied" Specification that is treated as "Required." You should have documentation that shows which applications have been instrumented in this manner.
§164.312(c)(2). Integrity of ePHI. An Organization is required to consider the various Risks to the Integrity of ePHI identified during each Risk Assessment to ensure that the ePHI has not been altered or destroyed in an unauthorized manner. As a practical matter, most Organizations will have to rely on their vendors to implement this kind of data authentication. You should document which systems have this functionality available.
§164.312(d). Authentication. An Organization is required to ensure that a person or entity ("Person") is in fact the Person who they claim to be before being allowed access to ePHI. This can only be accomplished by requiring the Person to provide proof of identity. You should document, on a system-by-system basis, how said Authentication is managed.There are a few basic ways to provide proof of identity for purposes of authentication (i.e. in addition to the Person's unique identifier): (1) require something known only to that Person, such as a password or PIN; (2) require something that the Person possesses, such as a smart card, a token, or a key; or (i.e. two-factor authentication which consists of "something you know and something you have"); (3) require something unique to the Person such as a biometric. Examples of biometrics include fingerprints, voice patterns, facial patterns or iris patterns.
§164.312(e)(2)(i). Transmission of ePHI. An Organization must review its current methods for transmitting ePHI across an open network. For example, if ePHI is transmitted through email over the Internet, or via some form of private or point-to-point network (or by other means), then an Organization must ensure that the integrity of the ePHI is safeguarded while in transit if it wants to take advantage of the Breach Notification safe harbor. The strategy and methods by which this integrity is maintained should be documented on a system-by-system basis. In general, the primary method for protecting the integrity of ePHI while in transit is through the use of standard network communications protocols.
§164.310 (a)(2)(i). Contingency Operations. An Organization is required to develop and document policies and procedures that address allowing authorized (and limiting unauthorized) physical access to ePHI facilities-which may extend outside of an actual office, and could include Workforce members' homes or other physical locations where they access ePHI during emergency mode operations.
§164.310 (a)(2)(ii). Facility Security Plan. An Organization is required to establish a Facility Security Plan that documents the use of physical access controls to an Organization's plant and equipment. These controls must ensure that only authorized individuals have access to facilities and equipment that contain ePHI.
§164.310 (a)(2)(iii). Access Control and Validation Procedures. An Organization is required to specifically align and document a Workforce member's access to ePHI with the member's role or function in the Organization. These functional or role-based access controls and validation mechanisms should be closely aligned with the Organization's Facility Security Plan.
§164.310 (a)(2)(iv). Maintenance Records. An Organization is required to document various types of security repairs and modifications such as changing locks, access cards, and installing new security devices. Information such as who authorized the repair, who actually did the repair, and the reason for the repair, should be logged.
§164.310 (b). Workstation Use. An Organization is required to specify and document the proper functions to be performed by electronic computing devices. Inappropriate use of devices may expose an Organization to Risks, such as virus attacks, compromise of Information Systems, breaches of ePHI, etc.
§164.310 (c). Workstation Security. An Organization is required to specify and document physical safeguards for mobile devices (e.g. PCs, laptops, pads, phones, etc.).
§164.310 (d)(2)(i). Disposal. An Organization is required to properly dispose of electronic media that contains ePHI and document same. The term electronic media includes electronic storage devices like hard disks, and portable storage devices of all kinds across all hardware devices.
§164.310 (d)(2)(ii). Media Re-Use. An Organization is required to properly remove ePHI from electronic media prior to making said media available for re-use and document same.
§164.310 (d)(2)(iii). Accountability. An Organization is required to inventory, document and track devices that store, access, transmit, or maintain ePHI.
§164.310 (d)(2)(iv). Data Backup & Storage. An Organization is required to produce exact copies of ePHI as needed prior to the movement of ePHI enabled hardware devices and document the strategy and methods for achieving this objective.
The Breach Notification Rule.
§164.402. Risk Assessment of Breach. You must have a documented methodology for determining when Breach Notification is triggered. Further, you must document each potential breach (i.e. Security Incident) so that you can determine, with a degree of rigor, whether or not Breach Notification has been triggered.
§164.404. Notification to Individuals. You must have model letters that demonstrate how patients would be notified if Breach Notification were triggered.
§164.404. Timeliness of Notification. Your Breach Notification methodology must document the various time triggers (e.g. to patients, to HHS, and to the media) that are pertinent once you have determined that Breach Notification has been triggered.
§164.404. Methods of Individual Notification. Your Breach Notification methodology must document the various methods (mail, website, 800 number, media) to be used (i.e. depending on the current state of your patient contact database) to notify patients once you have determined that Breach Notification has been triggered.
§164.404. Methods of Individual Notification. Your Breach Notification methodology must document the required content to be used when notifying patients once you have determined that Breach Notification has been triggered.
§164.406. Notification to the Media.Your Breach Notification methodology must document the required content to be used to notify the Media once you have determined that Breach Notification has been triggered.
§164.408. Notification to the Secretary. Your Breach Notification methodology must document the required content to be used to notify the Secretary once you have determined that Breach Notification has been triggered.
§164.410 Notification by a Business Associate. Your Breach Notification methodology must document the timeframes and the strategy and methods to be used when a Business Associate discovers a Breach in an information system that that the Business Associate controls.
Are we having fun yet? This is a comprehensive, but not exhaustive
list of what HIPAA requires by way of documentation. Our Subscription Plan
provides the most direct route in the marketplace for satisfying most if these requirements.