Auditing Policy

RosettaHealth shall audit access and activity of electronic protected health information (ePHI) applications and systems in order to ensure compliance. The Security Rule requires healthcare organizations to implement reasonable hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Audit activities may be limited by application, system, and/or network auditing capabilities and resources. RosettaHealth shall make reasonable and good-faith efforts to safeguard information privacy and security through a well-thought-out approach to auditing that is consistent with available resources.

It is the policy of RosettaHealth to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, RosettaHealth shall audit access and activity to detect, report, and guard against:

• Network vulnerabilities and intrusions;

• Breaches in confidentiality and security of patient protected health information;

• Performance problems and flaws in applications;

• Improper alteration or destruction of ePHI;

• Out of date software and/or software known to have vulnerabilities.

This policy applies to all RosettaHealth systems that store, transmit, or process ePHI. As RosettaHealth uses ClearDATA as our system/infrastructure provider of AWS services, auditing policies activities include those that ClearDATA specifies.

Applicable Standards

Applicable Standards from the HITRUST Common Security Framework

• 0.a - Information Security Management Program

• 01.a - Access Control Policy

• 01.b - User Registration

• 01.c - Privilege Management

• 09.aa - Audit Logging

• 09.ac - Protection of Log Information

• 09.ab - Monitoring System Use

• 09.ad - Administrator and Operator Logs

• 06.e - Prevention of Misuse of Information

Applicable Standards from the HIPAA Security Rule

• 164.308(a)(1)(ii)(D) - Information System Activity Review

• 164.308(a)(5)(ii)(B) & (C) - Protection from Malicious Software & Log-in Monitoring

• 164.308(a)(2) - HIPAA Security Rule Periodic Evaluation

• 164.312(b) - Audit Controls

• 164.312(c)(2) - Mechanism to Authenticate ePHI

• 164.312(e)(2)(i) - Integrity Controls

Auditing Policies

1. Responsibility for auditing information system access and activity is assigned to RosettaHealth’s Security Officer. The Security Officer shall:

   1. Assign the task of generating reports/alerts for audit activities to the workforce member responsible for the application, system, or network;

   2. Assign the task of reviewing the audit reports/alerts to the workforce member responsible for the application, system, or network, the Privacy Officer, or any other individual determined to be appropriate for the task;

   3. All connections to RosettaHealth are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.

2. RosettaHealth’s auditing processes shall address access and activity at the following levels listed below.

   1. HealthBus Services: All platform services produce audit trails that capture the caller of the service (identified by either username, RosettaHealth uniqueID, or OID), the service requested, timestamp of the request and the outcome of the request.

   2. Server: Server level audit trails generally monitor and log privileged user activities, applications accessed, and other system defined specific actions. These are captured by ClearDATA audit mechanisms and pushed to AWS CloudWatch.

   3. AWS Services: AWS Service event audit trails capture all events that occur on AWS services.

   4. For multi-step information flows, an audit record will be generated and captured for each significant processing step.

Monitoring and Alerting

1. Collected audit information is continually monitored. Based on specific contextual rules this monitored information may generate an alert to RosettaHealth admins: There are 4 levels of alerts:

   1. Level 0 (Informational Alert): An event has occurred that needs to be noted but does not necessarily require follow-up action (ex ssh login).

   2. Level 1 (Error Alert): An error condition has been encountered (including failed system access/authentication) but doesn’t present a threat to normal system operations. It needs to be reviewed within 24 hours.

   3. Level 2 (Exception Alert): An exception condition has been encountered that may indicate an issue that can impact normal system operations. It needs to be addressed within 12 hours.

   4. Level 3 (Failure Alert): A component is non-responsive and needs to be addressed immediately.

2. For each component alert level is an alerting mechanism intended to notify RosettaHealth administrators. Current mechanisms include:

   1. Level 0: Slack Channel Alert0:

   2. Level 1: Slack Channel Alert1:

   3. Level 2: Slack Channel Alert2:

   4. Level 3: PagerDuty

3. All RosettaHealth Admin personnel are subscribed via email to PagerDuty status alert system (https://status.pagerduty.com) which provides alerts if PagerDuty uptime status changes.

4. Alerts generated from ClearDATA’s Server and Network level monitoring are communicated to the Security Officer via phone and email.

5. Monitoring and alerting polices are reviewed on a yearly basis or as needed by changes in the HealthBus platform or platform operations

Audit Requests

1. A request may be made for an audit for a specific cause. The request may come from a variety of sources including, but not limited to, Privacy Officer, Security Officer, or Customer.

2. A request for an audit for specific cause must include time frame, frequency, and nature of the request. The request must be reviewed and approved by RosettaHealth’s Privacy or Security Officer.

3. A request for an audit must be approved by RosettaHealth’s Privacy Officer and/or Security Officer before proceeding. Under no circumstances shall detailed audit information be shared with parties without proper permissions and access to see such data.

   • Should the audit disclose that a workforce member has accessed ePHI inappropriately, the minimum necessary/least privileged information shall be shared with RosettaHealth’s Security Officer to determine appropriate sanction/corrective disciplinary action.

   • Only de-identified information shall be shared with Customer or Partner regarding the results of the investigative audit process. This information will be communicated to the appropriate personnel by RosettaHealth’s Privacy Officer or designee. Prior to communicating with customers and partners regarding an audit, it is recommended that RosettaHealth consider seeking risk management and/or legal counsel.

Audit Reporting

Reporting of auditable events is done using AWS CloudTrail for AWS events and AWS QuickSight for HealthBus Platform events.

Review of Audit Findings

1. Audit information regarding system access that is routinely gathered must be reviewed in a timely manner by the responsible workforce member(s).

2. Reports of audit results shall be limited to internal use on a minimum necessary/need-to-know basis. Audit results shall not be disclosed externally without administrative and/or legal counsel approval.

3. Security audits constitute an internal, confidential monitoring practice that may be included in RosettaHealth’s performance improvement activities and reporting. Care shall be taken to ensure that the results of the audits are disclosed to administrative level oversight structures only and that information which may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports (individually-identifiable e PHI shall not be included in the reports).

4. Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the responsible workforce members, Customers, and/or Partners.

Audit Log Security Controls and Backup

1. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy.

2. All audit logs are protected in transit and encrypted at rest to maintain the integrity of the logs.

3. Audit logs shall be stored as objects in AWS S3 with the following properties:

   • Bucket Encryption Enabled (logs are encrypted at rest)
   • Bucket Versioning Enabled (logs are versioned)
   • Object Lock applied to the bucket to prevent deletion of log objects.

Workforce Training, Education, Awareness and Responsibilities

1. RosettaHealth workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI. RosettaHealth’s commitment to auditing access and activity of the information applications, systems, and networks is communicated through new employee orientation, ongoing training opportunities and events, and applicable policies. RosettaHealth workforce members are made aware of responsibilities with regard to privacy and security of information as well as applicable sanctions/corrective disciplinary actions should the auditing process detect a workforce member’s failure to comply with organizational policies.

2. RosettaHealth Customers are provided with necessary information to understand RosettaHealth auditing capabilities.

External Audits of Information Access and Activity

1. Prior to contracting with an external audit firm, RosettaHealth shall:

   • Outline the audit responsibility, authority, and accountability;

   • Ensure technical competence of the audit firm staff;

   • Require the audit firm’s adherence to applicable codes of professional ethics;

   • Assign organizational responsibility for supervision of the external audit firm.

Retention of Audit Data

1. Audit logs shall be maintained based on organizational needs. There is no standard or law addressing the retention of audit log/trail information. Retention of this information shall be based on:

   • Organizational history and experience.

   • Available storage space.

2. Audit log data is retained locally on the originating system for a 60 day period. Beyond that, log data is encrypted and moved to warm storage (currently S3) using automated scripts, and is retained for a minimum of one year.