Chapter - 2 : HIPAA Compliance
This chapter covers HIPAA and HITECH compliance for OIDG.
Oracle and HIPAA
The Healthcare Insurance Portability and Accountability Act of 1996 (HIPAA) requires Covered Entities to implement processes and safeguards designed to protect the privacy and security of electronic protected health information (ePHI or simply PHI). HIPAA has evolved through subsequent legislation:
- The Privacy Rule was added in December 2000. It gives patients rights over their health information and sets rules for how information is used, shared, accessed and protected. Moreover, the rule explicitly lists ePHI identifiers like name and social security number.
- The Security Rule was added in February 2003.
- The HITECH Act that was passed in February 2009 which dictates how the privacy and security of health information must be managed by Covered Entities and Business Associates (or BAs).
- The Omnibus Rule that is effective as of September 2013. Among other things, it extended the definition of a BA to parties that create, receive, maintain and transmit PHI on behalf of a Covered Entity.
By definition of the Omnibus Rule, Oracle is considered a BA when Oracle performs functions on behalf of a Covered Entity that involve access to PHI. That is even the case when no specific customer Business Associate Agreement (or BAA) is in place. To address the requirements coming from this, Oracle implemented:
- Standard BAAs with its suppliers as well as standard BAAs for use by Oracle's customers that enables them to fulfill their requirements.
- Processes that address compliance with the administrative, physical and technical requirements of the Security Rule.
- Annual audits that are conducted by a third party to assess Oracle's level of compliance. This includes cloud services and consulting engagements.
HIPAA by Design
HIPAA and HITECH require covered entities to
- Ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain or transmit;
- Identify and protect against reasonably anticipated threats to the security or integrity of the information;
- Protect against reasonably anticipated, impermissible uses or disclosures; and
- Ensure compliance by their workforce.
The Privacy rule is more functional in nature and will be an integral part of the design of the application/service as this is exposed to the user community. The Security Rule is a series of administrative, technical, and physical security safeguards and related policies and procedures designed to require covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting ePHI. Both rules impact the development process but it is the Security rule that has proved more intractable as there are requirements to not only follow the rule but to show that the rule is being followed.
Covered entities are required to comply with every security rule, however, the security rule categorizes certain standards as "addressable," while others are "required."
- Required - These implementation specifications must be implemented.
- Addressable - The "addressable" designation does not mean that an implementation specification is optional. However, it permits covered entities to determine whether the addressable implementation specification is reasonable and appropriate for that covered entity. If it is not, the security rule allows the covered entity to adopt an alternative measure that achieves the purpose of the standard, if the alternative measure is reasonable and appropriate.
There are a number of Administrative Standards and Technical Standards that have a direct impact on the development process. Examples of these are listed in the following table. The last column contains examples that illustrate how the OIDG application development process or architecture (including the Oracle technology stack) handles the rule.
| Rule | Implementation | Oracle and OIDG Solution |
|---|---|---|
| ADMINISTRATIVE - Security Management Process - 164.308 (a)(1) Risk analysis (Required) | Assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of PHI held by the covered entity or business associate. | Oracle Global Product Security review for every major release of an OIDG application. Static and dynamic code scans are required to be run for every release. Identified high and critical security vulnerabilities must be addressed before release. |
| TECHNICAL - Security Management Process 164.312(a) -Mixed | (1) Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).
(2) Implementation specifications: (i) Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity. (ii) Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency. (iii) Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. (iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information |
By default, OIDG only accepts requests from authenticated, identifiable users. OIDG provides role based authorization to associate application roles with users. The WebLogic runtime environment implements account inactivity / session timeout. Users have to re-authenticate in order to continue working. Any web traffic should be encrypted using TLS/SSL, at least from client to load balancer / DMZ (more on this elsewhere in this guide). For data at rest the Oracle database offers the Transparent Data Encryption feature. |
| TECHNICAL - Audit Controls 164.312 (b) (Required) | Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. |
OIDG does not store PHI data. Requests containing PHI data can be placed in sFTP files or local folders. Oracle recommends that those files be encrypted at rest. Regardless, OIDG logs user authentication.
|
| TECHNICAL - Integrity 164.308 (a)(3) (Required) | Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information. | Users who have access to the ePHI should be minimized. For that, customers should apply the Principle of Least Privilege (see elsewhere in this guide) and the Principle of Minimum level of access. OIDG requires that users are explicitly provisioned to access the application (through the provisioning service). Moreover, users should not be granted access to system functions (and associated data) that they do not need for their work. |
| TECHNICAL - Transmission Security 164.312 (e) (Mixed) | Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.
(2) Implementation specifications: (i) Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. (ii) Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. |
Customers should use TLS/SSL and sFTP to effectively protect data in transit. Customers should use OpenPGP encryption standards to protect files at rest. Consider the use of Oracle Advanced Security SQLnet encryption between the mid-tiers and the database if required. |
HIPAA and OIDG Development and Consulting resources
OIDG Development and Consulting resources interact with customers in various ways. Customers make use of OIDG systems through on premise deployments. Oracle staff may be required to access OIDG deployment environments for support or maintenance purposes. Oracle staff utilizes dedicated systems and environments specifically designed to retain PHI. For example, any data stored on Oracle consulting laptops is encrypted; Oracle Support systems are regularly audited for compliance. All Oracle employees are required to take the Information Protection Awareness training upon employment and every two years. Oracle employees with access to ePHI environments are required to take annual HIPAA trainings. Training is provided through Oracle University and completion is tracked.