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 OHI Components applications development process or architecture (including the Oracle technology stack) handles the rule. Alternatively, it identifies how customers implementing OHI Components applications should deal with the rule.

Rule	Implementation	Oracle & OHI 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 OHI Components application. Specific security audits for Oracle Cloud deployments.
TECHNICAL - Security Management Process 164.312(a) -Mixed	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, OHI Components applications only accept requests from authenticated, identifiable users. OHI Components applications provide role based authorization to associate 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.	OHI Components applications record access, even read-only access, to PHI data. For example: OHI Claims logs which users have viewed specific claims OHI Alternative Reimbursement logs which users have viewed data for specific members
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. OHI Components applications require that users are explicitly provisioned to access an 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 to effectively protect data in transit. Consider the use of Oracle Advanced Security SQLnet encryption between the mid-tiers and the database if required.

Rule

Implementation

Oracle & OHI 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 OHI Components application.

Specific security audits for Oracle Cloud deployments.

TECHNICAL - Security Management Process 164.312(a) -Mixed

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, OHI Components applications only accept requests from authenticated, identifiable users.

OHI Components applications provide role based authorization to associate 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.

OHI Components applications record access, even read-only access, to PHI data. For example:

OHI Claims logs which users have viewed specific claims
OHI Alternative Reimbursement logs which users have viewed data for specific members

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. OHI Components applications require that users are explicitly provisioned to access an 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 to effectively protect data in transit. Consider the use of Oracle Advanced Security SQLnet encryption between the mid-tiers and the database if required.