Computer Technology

COMPUTER technology
BY DAVID OATWAY

A road map to HIPAA compliance

The Security Rule is more limited in scope than the Privacy Rule. While the Privacy Rule covered all protected health information (PHI), paper or electronic, the Security Rule applies only to electronically stored or transmitted PHI. Like the Privacy Rule, the Security Rule emphasizes reasonableness and does not specify any specific technology to meet its requirements. It allows scaling of responses, depending on each facility’s size and technologic environment. Each facility is required to assess its status and address its vulnerabilities within its own organizational framework, as long as it complies with all basic standards and evaluates, documents, and acts appropriately regarding addressable issues. To better understand the distinction between “required” and “addressable”-key to understanding this article-see “Implementation Specifications: Required versus Addressable.”

Road Map to Full Compliance
Getting to compliance will necessitate a deliberate effort to identify vulnerabilities and threats to the confidentiality, integrity, and availability of electronic PHI, or ePHI. All of the following steps must be taken, but the exact order will depend on the circumstances of each facility. Each standard will be identified as being “Required” (R) or “Addressable” (A) in accordance with the Final Rule and a suggestion as to timing: “Now,” or “Later.” While it would be desirable to do everything now, the reality of limited resources and the need to collect and analyze data before taking some actions dictate a phased approach. The timing suggestions must be evaluated by each facility-they are not part of the rule! In some facilities, standards suggested as “Later” may already have been met. The suggestions are intended for facilities without the current capability to comply with the standard.

We suggest the facility’s security official (and there must be one) use a HIPAA Security Matrix to ensure that each requirement is addressed. A comprehensive HIPAA Security Matrix is needed to document all issues related to the security of electronic PHI. Each facility will need to ensure that the security analysis they perform is comprehensive for their facility. Typically, a security matrix may be 20 pages or more. (A sample matrix for nursing facilities that can be tailored to individual facilities is available by e-mailing the author.) Documentation related to Security Rule analysis and actions is required to be maintained in a written record (which may be electronic) that includes the Risk Analysis (see below) and reports of actions, policies, and procedures. Start it now.

Implementation specifications are either “required” or “addressable.” If a standard includes a required implementation, the covered entity must assess the risks and must implement the safeguard specified by the rule. If a standard includes an addressable implementation specification, a covered entity must:

1. Assess whether each implementation specification is a reasonable and appropriate safeguard in its environment; and
2. As applicable to the entity:
   1. Implement the implementation speci-fication if reasonable and appropriate; or
   2. if this is not reasonable or appropri-ate, document the reasons, and
   3. Implement an equivalent alternative measure, if reasonable and appropriate.

Risk Analysis (R, Now). The Risk Analysis is the foundation documentation for the compliance effort. Take time to do this well, since many other actions depend on it. Each facility must determine the particular vulnerabilities of its ePHI. This means considering “all relevant losses” that would be expected if the security measures were not in place. Examples would include losses caused by unauthorized uses and disclosures or any loss of data integrity, such as that caused by a system crash with no current backup. The Risk Analysis should use the Security Matrix described above as a tool to ensure that all risks are identified and evaluated. The Risk Analysis must be repeated often enough to ensure that the security measures continue to be adequate for providing the protection required by the rule.

Authorization and/or Supervision (A, Now ). Related to the Privacy Rule, policies and procedures must be in place to ensure that only authorized staff have access to ePHI.

Workforce Clearance Procedure (A, Now). Related to the Privacy Rule, policies and procedures must be in place to ensure that only properly cleared staff have authorized access to ePHI.

Termination Procedures (A, Now). Related to the Privacy Rule, policies and procedures must be in place to ensure that when staff are terminated, so is their authorization to access ePHI.

Access Authorization (A, Now). Related to the Privacy Rule, policies and procedures must be in place to ensure that authorized staff have access to the data they need. As changes are made in software applications to facilitate compliance with the Security Rule, this issue will need to be revisited.

Security Reminders (A, Now). Initiate security reminders using tools appropriate to your facility. Newsletters, e-mails, circulated tips, bulletin board notices, etc. can all help raise awareness.

Protection from Malicious Software (A, Now). This most definitely can’t wait! There must be policies and procedures to guard against, detect, and report viruses, worms, and other malicious software. Properly configured firewalls for all outside connections are essential. Current antivirus software with regular updates should be running on all workstations that are vulnerable to attack. Loading software to network-connected or stand-alone workstations should be restricted to designated staff only.

Data Backup Plan (R, Now). This should already be in place in all facilities-but typically isn’t. We suggest that compliance with this requirement be supervised by the security official immediately.

Facility Access Control and Validation (A, Now). Control access to physical components and to software for testing and revision. This means that physical access to servers and storage must be controlled and records maintained on individuals using the system (including guests).

Workstation Use, Device and Media Controls: Disposal (R, Now). Address the secure final disposal of media or hardware containing ePHI.

Workstation Use, Device and Media Controls: Re-use (R, Now). Address the re-use of media or hardware containing ePHI.

Risk Management (R, Later). Since this depends on the Risk Analysis, this has to be delayed until the Risk Analysis task is complete.

Evaluation (R, Later). Perform periodic technical and nontechnical evaluation of the security plan.

Sanction Policy (R, Later). Determine the actions to be taken for breaches of the security policies.

Isolating Healthcare Clearinghouse Functions (R, Later, if needed). In larger organizations, clearinghouse data (i.e., data aggregated from several facilities) must be protected from access by outside facilities.

Access Establishment and Modification (A, Later). If the facility’s current software supports access rights management, ensure that access rights are indeed being managed.

The purpose of the Final Rule is to adopt national standards for safeguards to protect the confidentiality, integrity, and availability of electronically protected health information (ePHI). This purpose has gained even greater importance since the commitment to work toward an electronic health record (EHR) as a national goal, supported by both major political parties. Before any EHR can be implemented, the goals of the Security Rule must be met. Two quotes from the actual Final Rule will help put the requirements in perspective:

General Requirements’45 CFR 164.306(a)
“Covered entities must do the following:

1. Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity creates, receives, maintains, or transmits.
2. Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.
3. Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part.
4. Ensure compliance with this subpart by its workforce.

Flexibility of approach’45 CFR 164.306(b)

1. Covered entities may use any security measures that allow the covered entity to reasonably and appropriately implement the standards and implementation specifications as specified in this subpart.
2. In deciding which security measures to use, a covered entity must take into account the following factors:
   1. The size, complexity, and capabilities of the covered entity.
   2. The covered entity’s technical infrastructure, hardware, and software security capabilities.
   3. The costs of security measures.
   4. The probability and criticality of potential risks to electronic protected health information.”

Person or Entity Authentication (R, Later). Ensure that the person or entity receiving ePHI is actually the person or entity it claims to be.

Access Control: Emergency Access Procedure (R, Later). Procedures must be available to access ePHI in an emergency, with an appropriate audit trail.

Login Monitoring (A, Later). Ensure all software or workstations that have access to ePHI will be capable of monitoring login attempts and reporting them. Vendors may have to upgrade their applications to provide the capabilities needed.

Information System Activity Review (R, Later). Review logs and other monitoring data, based on the above.

Password Management (A, Later). How passwords are distributed and managed depends upon the application and facility policy.

Security Incident: Response and Reporting (R, Later). Since this partially depends on the Risk Analysis, this may be delayed until the Risk Analysis task is complete.

Security Incident: Contingency Plan (R, Later). Based on threats determined in the Risk Analysis.

Disaster Recovery Plan (R, Later). Based on threats determined in the Risk Analysis. If your facility is highly automated, this may take a higher priority.

Emergency-Mode Operation Plan (R, Later). Based on threats determined in the Risk Analysis. If your facility is highly automated, this may take a higher priority.

Testing and Revision Procedures (R, Later). The emergency plans must include periodic testing and revision of all components of the system. For example, testing the backup and recovery of the system and data from crashes is essential to having confidence in the procedure. Procedures for testing under controlled conditions, carrying out the tests, and documenting their results are required to ensure the data will be protected.

Applications and Data Criticality Analysis (A, Later). Assess the criticality of specific applications and data in support of other contingency plans. This could be performed as part of the overall risk assessment.

Business Associate (written contract or other arrangement) (R, Later). Requires the Business Associate comply with the requirements to safeguard the confidentiality, integrity, and availability of the organization’s ePHI.

Contingency Operations (A, Later). Part of the disaster recovery plan.

Facility Security Plan (A, Later). Plan to safeguard the facility against threats identified in the Risk Analysis.

Maintenance Records (A, Later). Maintain records of all repairs and modifications to the facility that are related to security (e.g., hardware, walls, doors, locks).

Workstation Use: Security (R, Later). Physical safeguards to restrict data access to authorized users performing authorized tasks. Depends on the Risk Analysis.

Workstation Use: Accountability (A, Later). Record the person(s) and routines involved for movements of hardware and electronic media.

Workstation Use: Data Backup and Storage (A, Later). Establish a policy to ensure that any ePHI on a workstation is backed up before movement of equipment.

Automatic Logoff (A, Later). Provide for terminating an electronic session after a predetermined time of inactivity. Meeting this standard will probably involve your software vendor if the software does not already comply.

Encryption and Decryption (A, Later). Implement a method to encrypt and decrypt ePHI whenever deemed appropriate. Do this based on vulnerabilities identified in the Risk Analysis. Although encryption of ePHI is not required globally, data that are being transmitted outside of the facility should be considered for encryption, depending on the security of the transmission medium. Encryption may be used for internal access control, but is not required.

Audit Controls (R, Later). Record and examine activity in information systems that contain ePHI. Logs of system activity must be generated and periodically evaluated by the facility. Unauthorized attempts to access the data, or attempts to penetrate the protections of the ePHI, will likely be identified in this way.

Mechanism to Authenticate ePHI (A, Later). There must be a mechanism to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Meeting this standard will probably involve consulting with your software vendors, if their software does not already comply.

Integrity Control (A, Later). When data are received electronically they must be protected from modification (on purpose or not) or the modification must be detected. For example, a laboratory report from a contract lab must be retained in its original form until the report is disposed of. Clinicians and administrators must be able to trust the data they are using for decisions.

Final Note
Throughout this guidance, the term “later” is relative. There is much to do, a limited time to do it, and possibly serious consequences for not doing it-all good reasons to at least start now.

• Department of Health and Human Services for all source documents related to HIPAA: https://aspe.hhs.gov/admnsimp/index.shtml.
• Healthcare Information and Management Systems Society (HIMSS) provides an excellent CPRI Toolkit that is available to non-members at www.himss.org/asp/cpritoolkit_homepage.asp. HIMSS has a Long Term Care Special Interest Group that is a great resource for information technology professionals in nursing facilities and other long-term care entities.
• American Health Information Management Association (AHIMA) provides analysis and guidance in the implementation of the HIPAA requirements. Some documents are available to nonmembers, but their members have access to extensive communities of practice (www.ahima.org).
• PricewaterhouseCoopers has an excellent interpretation of the Security Rule at: www.pwchealth.com/cgi-local/hcregister.cgi?link=pdf/securityrules.pdf.
• Jim Albert of Masonicare in Connecticut and other members of the HIPAA Workgroup for the Connecticut Association of Not-for-profit Providers For the Aging (CANPFA) have developed several excellent worksheets and draft policies that the organizations are willing to share. To request copies, e-mail the author of this article.

NOTE: This article is not intended to be legal advice, but rather the author’s interpretation and understanding of the current Health Insurance Reform: Security Standards; Final Rule, published February 20, 2003. Facilities should always review compliance issues with competent legal counsel.