Chapter 1

Security Logging and Monitoring

This document outlines AccuCode AI’s standards and requirements for logging information related to the processing of healthcare documents. Proper logging is essential for security monitoring, incident response, compliance, and troubleshooting. All employees and systems that handle protected health information (PHI) must adhere to these logging standards.

Questions about this policy should be directed to the InfoSec team at security@accucodeai.com.

Subsections of Security Logging and Monitoring

Information Logging Standard

Version1.0.5 Last Updated2024-03-18 APPROVED

1. Overview

Logging from critical systems, applications, and services can provide key information and potential indicators of compromise. Although logging information may not be viewed on a daily basis, it is critical to have from a forensics standpoint. This standard outlines the requirements for logging in systems that handle Protected Health Information (PHI) and Personally Identifiable Information (PII).

2. Purpose

The purpose of this document is to identify specific requirements that information systems must meet in order to generate appropriate audit logs and integrate with AccuCode AI’s log management function. The goal is to ensure that PHI and PII are never logged in clear text, and are always redacted when possible.

3. Scope

This policy applies to all production systems at AccuCode AI that process, store, or transmit PHI or PII.

4. Policy

4.1 General Requirements

All systems that handle PHI, PII, accept network connections, or make access control decisions shall record and retain audit logging information sufficient to answer the following questions:

  1. What activity was performed?
  2. Who or what performed the activity, including where or on what system the activity was performed from (subject)?
  3. What the activity was performed on (object)?
  4. When was the activity performed?
  5. What tool(s) was the activity used to perform the activity?
  6. What was the status (such as success vs. failure), outcome, or result of the activity?

4.2 PHI and PII Logging Requirements

In addition to the general logging requirements, systems handling PHI and PII must adhere to the following:

  1. PHI and PII must never be logged in clear text.
  2. If PHI or PII must be logged, it should be redacted, masked, or hashed.
  3. Access to systems containing PHI and PII must be logged.
  4. Failed access attempts to systems or data containing PHI and PII must be logged.

4.3 Activities to be Logged

Logs shall be created whenever any of the following activities are requested to be performed by the system:

  1. Create, read, update, or delete PHI or PII
  2. Create, update, or delete information not covered in #1
  3. Initiate or accept a network connection
  4. User authentication and authorization for activities covered in #1 or #2
  5. Grant, modify, or revoke access rights
  6. System, network, or services configuration changes
  7. Application process startup, shutdown, or restart
  8. Application process abort, failure, or abnormal end
  9. Detection of suspicious/malicious activity

4.4 Elements of the Log

Logs shall identify or contain at least the following elements, directly or indirectly:

  1. Type of action
  2. Subsystem performing the action
  3. Identifiers for the subject requesting the action
  4. Identifiers for the object the action was performed on
  5. Before and after values when action involves updating data
  6. Date and time the action was performed, including time-zone
  7. Whether the action was allowed or denied by access-control mechanisms
  8. Description and/or reason-codes of why the action was denied

4.5 Log Retention

Audit logs must be retained for a minimum of 180 days.

4.6 Formatting and Storage

The system shall support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting. Acceptable formats include:

  1. Windows Event Logs collected by a centralized log management system
  2. Logs in a documented format sent via syslog protocols to a centralized log management system
  3. Logs stored in an PostgreSQL database that itself generates audit logs
  4. Other open logging mechanisms that support the requirements

5. Policy Compliance

5.1 Compliance Measurement

The InfoSec team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the InfoSec team in advance.

5.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Medical Coding System Logging Standard

Version1.0.5 Last Updated2023-10-20 APPROVED

1. Overview

Logging from the medical coding AI system can provide critical information for auditing, compliance, and understanding how the AI model arrived at specific coding decisions. Although this logging information may not be viewed on a daily basis, it is essential to have from a forensics and accountability standpoint. This standard outlines the requirements for logging in the medical coding AI system that handles Protected Health Information (PHI).

2. Purpose

The purpose of this document is to identify specific requirements that the medical coding AI system must meet in order to generate appropriate audit logs and integrate with AccuCode AI’s log management function. The goal is to ensure that PHI is never logged in clear text and is always redacted before being stored for auditing purposes.

3. Scope

This policy applies to the medical coding AI system at AccuCode AI that processes PHI from healthcare documents such as patient charts, for the purpose of automating healthcare billing and clinical abstraction.

4. Policy

4.1 General Requirements

The medical coding AI system shall record and retain audit logging information sufficient to answer the following questions:

  1. What specific healthcare document was processed?
  2. What AI model or version of the model performed the coding?
  3. When was the coding performed?
  4. What codes were assigned by the AI system?
  5. What was the confidence level or probability for each code assigned?
  6. What key features or evidence from the document were used to assign each code?

4.2 PHI Logging Requirements

In addition to the general logging requirements, the medical coding AI system handling PHI must adhere to the following:

  1. PHI must never be logged in clear text.
  2. PHI must be redacted, masked, or hashed before logging.
  3. Access to the AI system must be logged.
  4. Failed access attempts to the AI system must be logged.

4.3 Activities to be Logged

Logs shall be created whenever any of the following activities are performed by the medical coding AI system:

  1. Healthcare document is uploaded or ingested
  2. AI model processes the healthcare document
  3. Codes are assigned to the healthcare document
  4. User authenticates to view the coding results and audit logs
  5. AI model is updated or re-trained on new data
  6. Detection of suspicious activity or model drift

4.4 Elements of the Log

Logs shall identify or contain at least the following elements, directly or indirectly:

  1. Document ID (masked)
  2. AI model name and version
  3. Date and time the coding was performed, including time-zone
  4. Assigned codes and their confidence levels/probabilities
  5. Key features or evidence used to assign each code, with PHI redacted
  6. User ID who accessed the results and audit logs
  7. Reason for any failures or exceptions in processing

4.5 Log Retention

Audit logs with PHI redacted must be retained for a minimum of 7 years for compliance purposes.

4.6 Formatting and Storage

The system shall support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting. Acceptable formats include:

  1. Logs in a documented format sent via syslog protocols to a centralized log management system
  2. Logs stored in a PostgreSQL database that itself generates audit logs
  3. Other open logging mechanisms that support the requirements

5. Policy Compliance

5.1 Compliance Measurement

The InfoSec team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the InfoSec team in advance.

5.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.