Generic Audit

Overview

The Audit and Change Tracking framework provides a standardized way to capture and retrieve data changes made to supported business entities.

Audit tracking is performed at the root entity level, ensuring that all relevant changes including those from related child entities are consolidated under a single audit trail. In cases where entities do not have a parent relationship, audit tracking is maintained at the entity and record level (for example, Reference Sheets and Reference Sheet Lines).

The framework records the following key operations:

  • Create

  • Update

  • Delete

For update operations, it captures field-level changes, including previous and new values, enabling detailed traceability of data over time.

Audit history can be retrieved for a specific root entity (such as Claim or Policy), with all related changes consolidated at the root level. It supports filtering, sorting, and pagination. The response includes the following details:

  • Operation

  • Timestamp

  • User information

  • Field-level changes (old and new values)

  • Readable attributes such as userName and entityName.

Generic Audit does not track changes made through Configuration Migration (CMT). CMT maintains its own migration-specific change tracking mechanism.

Audit Log Fields

Field Name Description

ROOT_TABLE_ID

Identifier of the root entity.

TABL_ID

Table identifier of the resource being changed.

ROOT_IDENTIFIER

Technical identifier of the root entity instance.

RECORD_IDENTIFIER

Technical identifier of the specific record.

CONTEXT

Context information used for display purposes.

DFUS_ID

Technical identifier of the dynamic field usage.

DYNAMIC_RECORD_REF

Reference value representing the dynamic record for meaningful context.

UPDATED_BY

Identifier of the user or system that made the change.

UPDATED_DATETIME

Date and time when the change was made.

OPERATION

Type of operation performed (Create, Update, or Delete).

FIELD_NAME

Name of the field that was changed.

OLD_VALUE

Previous value of the field (standard-length values).

NEW_VALUE

New value of the field (standard-length values).

OLD_VALUE_CLOB

Previous value for large text data.

NEW_VALUE_CLOB

New value for large text data.

OLD_CCY_CODE

Currency code associated with the old value (for amount fields).

NEW_CCY_CODE

Currency code associated with the new value (for amount fields).
For information on how to retrieve audit history, see Generic Audit API.

Use Cases

Use Case 1: Claim Lifecycle and Updates

Use Case Description Entity Context Dynamic Record Field Name Old Value New Value Operation Updated By Updated Datetime

Claim is created

Claim

CLA001

CREATE

EDI User

6 Apr 2026 10:11:26

Claim is adjusted by derivation rule

Claim

CLA001

derivedAdjustmentFlag

N

Y

UPDATE

Internal System User

6 Apr 2026 15:24:00

Claim is finalized

Claim

CLA001

status

INITIAL

FINALIZED

UPDATE

Internal System User

6 Apr 2026 10:11:27

Claim is unfinalized by User A

Claim

CLA001

status

FINALIZED

CHANGE

UPDATE

User A

6 Apr 2026 13:11:26

User A adds a dynamic record

Claim

CLA001

paymentInfo#00001~US-Provider

CREATE

User A

6 Apr 2026 13:15:26

Claim line is adjusted by User A

Claim Line

1

allowedAmount

400

430

UPDATE

User A

6 Apr 2026 13:17:26

Claim line is adjusted by derivation rule

Claim Line

1

amountOverrideApplied

N

Y

UPDATE

Internal System User

6 Apr 2026 13:17:29

Claim is submitted (pended)

Claim

CLA001

status

CHANGE

MANUAL ADJUDICATION

UPDATE

Internal System User

6 Apr 2026 13:18:26

Claim is reverted to Change by User B

Claim

CLA001

status

MANUAL ADJUDICATION

CHANGE

UPDATE

User B

6 Apr 2026 15:11:26

User B updates payment info

Claim

CLA001

paymentInfo#00001~US-Provider

verified

N

Y

UPDATE

User B

6 Apr 2026 15:19:26

User B updates external claims data

External Data

CLA001

providerContactDetailUpdated

N

Y

UPDATE

User B

6 Apr 2026 15:23:26

Claim is finalized by User B

Claim

CLA001

status

CHANGE

FINALIZED

UPDATE

Internal System User

6 Apr 2026 15:24:20

Use Case 2: Policy Versioning and Enrollment Updates

Use Case Description Entity Context Dynamic Record Field Name Old Value New Value Operation Updated By Updated Datetime

Policy is created via portal

Policy

POL001~V1

CREATE

Portal User

20 Apr 2026 10:00:00

Policy V1 is approved

Policy

POL001~V1

status

EDIT

APPROVED

UPDATE

Internal System User

20 Apr 2026 10:04:00

Policy moved to Edit

Policy

POL001~V2

status

APPROVED

EDIT

UPDATE

User A

20 Apr 2026 10:05:00

Policy enrollment updated

Policy Enrollment

POL001~V2

verified

N

Y

UPDATE

User A

20 Apr 2026 10:10:00

Policy V2 is approved

Policy

POL001~V2

status

EDIT

APPROVED

UPDATE

Internal System User

20 Apr 2026 10:05:01

Policy moved to Edit

Policy

POL001~V3

status

APPROVED

EDIT

UPDATE

User A

20 Apr 2026 10:05:00

Policy enrollment updated

Policy Enrollment

POL001~V3

enrollType

CHILD

SPOUSE

UPDATE

User A

20 Apr 2026 10:10:00

Policy submitted

Policy

POL001~V3

status

EDIT

IN PROCESS

UPDATE

Internal System User

20 Apr 2026 10:15:00

Policy pended

Policy

POL001~V3

status

IN PROCESS

PENDED

UPDATE

Internal System User

20 Apr 2026 10:15:05

Policy moved to Edit

Policy

POL001~V3

status

PENDED

EDIT

UPDATE

User A

20 Apr 2026 10:18:00

Policy enrollment updated

Policy Enrollment

POL001~V3

enrollType

DEPENDENT

PRIMARY

UPDATE

User A

20 Apr 2026 10:20:00

Policy approved

Policy

POL001~V3

status

EDIT

APPROVED

UPDATE

Internal System User

20 Apr 2026 10:20:05

When operational data is purged, the associated audit records are also purged. Configuration audit data is retained according to the configured retention period and is purged through the configured audit purge process. See Auto Purge for more details.