Resource Auditing

This feature monitors user access and user updates to protected health information (PHI) and personally identifiable information (PII) through the HTTP application programming interface (API). All HTTP resources that link a person to PHI and all resources that contain PII are monitored. Whenever a user or a client application retrieves one of these resources or issues an operation on one of these resources, the application creates an entry in a dedicated log.

System property ohi.logging.target determines where the system stores audit messages. Possible values:

  • log: PHI access is logged using any configured Logback Appender for which the PHI filter is applied. An example of such a Logback Appender is the RollingFileAppender.

  • database: audit messages for PHI access are persisted in the database as part of the HTTP API request and can be accessed via the generic/logphievents resource.

PHI logs in the SaaS database are retained for 60 days. After that, they are moved to Object Storage. See Move PHI Logs to Object Storage for more details.

This feature is limited to logging the HTTP API operations on monitored resources. It does not trigger events.

The set of monitored resources is limited to:

  • The person (including insurable entity and insurable person) resource and its detail resources

  • Any resource representing operational information linked to an insurable entity or a family

An audit log entry has the following parts:

Table 1. Resource Auditing
Key Value Description

Time stamp

When PHI data is accessed.

keyword

All messages start with the tag "ACCESS" (not shown in the generic/logphievents payload).

user

The login name of the user (specified as 'system' for internal system user).

resource

The name of the resource that was accessed.

id

The technical ID of the resource that was accessed.

relatedKey

The code of the relation, family or insurable object that is in context (if applicable).

relatedId

The technical ID of the relation or insurable entity resource that is in context (if applicable).

method

The operation (GET, PUT, POST, PATCH or DELETE) issued on the resource.

accessScope

Specifies whether the action targets a single record or multiple records.

sessionId

Specifies the session identifier provided by the caller. Applies only to SaaS and UI requests.

accessTokenId

Specifies the access token identifier associated with the request. Applies only to SaaS and non-UI requests.

Monitored Resources

The following resources are monitored in Claims:

  • adjudicationcases

  • authorizations

  • base financial object

  • claims

    • claimlines

  • ctrclaims

    • ctrclaimlines

  • episodes

  • financial transactions

    • financial transaction details

  • limitcounters

    • limitconsumptions

  • insurableentities

    • insurablepersons

  • persons

    • addresses

    • assignedproviders

    • bankaccountnumbers

    • eligibilitychecks

    • maritalstatuses

    • persontitles

    • relationidentifiers

    • personcoveredservices

  • policyproducts

  • policyfamilies

  • providerlimitcounters

  • regimecounters

    • regimeconsumptions

  • registrations

In addition to resource access logging, the entities listed under monitored resources are, where applicable, also subject to generic audit tracking for data changes.

Audit API

Access to the Generic Audit API is integrated with the standard PHI/PII resource auditing framework. Each request to retrieve audit data generates a single resource audit log entry.

Example

A user retrieves the audit history for person MEM12345 by sending a POST request to the Generic Audit API. The request returns all matching audit records for the person. Regardless of the number of audit records returned, only one resource audit log entry is created for the API request.

genericaudit

2026/04/03 11:10:34; …​ ; {keyword=ACCESS, user=JONES, resource=personsaudit, id=856266305,method=POST}

Examples

The examples in this section show sample audit log entries for accessing different resources, such as persons, claims, authorizations, counters, and policy products. Each entry records an HTTP operation (such as GET, POST, PATCH, or DELETE) along with timestamps, user actions, and resource-specific metadata to help monitor user activity.

The examples in this section show entries from the database audit log. The same information is also described in JSON format, as shown below:

{
   "id": "610121334328",
   "application": "claims",
   "applicationVersion": "4.25.2.0.0-SNAPSHOT",
   "eventDate": "2025-08-07",
   "eventLogger": "com.oracle.healthinsurance.http.api.audit.BaseHttpAuditor",
   "instanceName": "claims_node2",
   "resourceId": "48872565692",
   "resourceMethod": "GET",
   "resourceName": "claims",
   "username": "JONES"
}

Persons

This example shows how person-related resources are logged in the audit file. Each entry logs details such as personal information, addresses, assigned providers, bank account numbers, eligibility checks, marital statuses, and person titles.

persons

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=persons, id=456719800, relatedKey=MEM12345,identifierstype=12348690, method=GET}

In this example, user Jones accessed the person with ID 456719800 and member key MEM12345 using the GET method. In this case, part 7 stores the technical ID of the identifier type (12348690) instead of the related ID.

For persons, part 7 does not contain the relatedId because it is the same as part 4, the ID. Instead, part 7 for persons holds the technical ID of the identifiertype.
Addresses

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=addresses, id=656266336, relatedKey=MEM12345, relatedId=456719800, method=POST}

assignedproviders

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=assignedproviders, id=956266336, relatedKey=MEM12345, relatedId=456719800, method=GET}

bankaccountnumbers

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=bankaccountnumbers, id=756266336, relatedKey=MEM12345, relatedId=456719800, method=DELETE}

eligibilitychecks

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=eligibilitychecks, id=856266336, relatedKey=MEM12345, relatedId=456719800, method=GET}

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=eligibilitychecks, id=856266335, method=GET}

maritalstatuses

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=maritalstatuses, id=456719800, relatedKey=MEM12345, relatedId=456719800, method=GET}

persontitles

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=persontitles, id=356266336, relatedKey=MEM12345, relatedId=456719800, method=PATCH}

Insurable Entities

The following examples show audit log entries for accessing insurable entities, such as general cars and insurable persons. Each entry shows the resource types, the action taken, and the related person or object key. For insurable persons, the log includes both relatedKey and relatedId to show the link to the person.

insurableentities

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=insurableentities, id=256266330, relatedKey=MEM12345, relatedId=456719800, method=GET}

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=insurableentities, id=276266330, relatedKey=CAR12345, method=GET}

Part 6 is not logged for insurable entities that are objects because it is identical to part 4.
insurablepersons

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=insurablepersons, id=2562663330, relatedKey=MEM12345, relatedId=456719800, method=GET}

Claims

The following examples show audit log entries for accessing various claim-related resources, including claims, claim lines, claim transaction repository (ctrclaims), and claim transaction repository lines (ctrclaimlines). Each entry logs the user action, such as creating, updating, or viewing a claim or claim line. For claim lines, if no insurable entity is referenced, that information is inherited from the claim. CTR claims and CTR claim lines do not log relatedId because they do not reference insurable entities directly. Instead, the serviced entity code is stored at the claim or claim line level.

claims

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=claims, id=256266331, relatedKey=MEM12345, relatedId=456719800, method=GET}

2017/03/02 13:22:12; …​ ; {keyword=ACCESS, user=JONES, resource=claims, id=245239330, method=PUT}

claimlines

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=claimlines, id=256266332, relatedKey=MEM12345, relatedId=456719800, method=POST}

If a claim line does not have a reference to an insurable entity, that information is picked up from the claim level.
ctrclaims

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=ctrclaims, id=256266331, relatedKey=MEM12345, method=GET}

2017/03/02 13:22:12; …​ ; {keyword=ACCESS, user=JONES, resource=ctrclaims, id=256266333, method=GET}

Part 6 is not logged for ctr claims because ctr claims do not have references to insurable entities; the code of the serviced (insurable) entity is stored as an attribute on the ctr claim.
ctrclaimlines

2017/03/01 15:56:02; …​ ;+{keyword=ACCESS, user=JONES, resource=ctrclaimlines, id=256266334, relatedKey=MEM12345, method=GET}+

If a ctr claim line does not have a specified serviced entity code, that information is picked up from the ctr claim level. Part 6 is not logged for ctr claim lines (same as for ctr claims).

Authorizations

The following example shows how access to the authorizations resource is logged in audit logs. Each log entry records key information such as the resource type, the authorization ID, the member key, and the action performed.

authorizations

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=authorizations, id=256266335, relatedKey=MEM12345, relatedId=456719800, method=GET}

Counters

The following example shows how counters are captured in the audit log. The entries track different types of counters, such as limit counters, limit consumptions, provider limit counters, and regime counters or consumptions. Each entry logs the counter ID, the member or family key, and the action performed.

limitcounters

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=limitcounters, id=256266336, relatedKey=MEM12345, relatedId=456719800, method=GET}

2017/03/02 13:22:12; …​ ; {keyword=ACCESS, user=JONES, resource=limitcounters, id=245239337, relatedKey=FAM12345, method=GET}

limitconsumptions

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=limitconsumptions, id=256266338, relatedKey=MEM12345, relatedId=456719800, method=GET}

2017/03/02 13:22:12; …​ ; {keyword=ACCESS, user=JONES, resource=limitconsumptions, id=256266339, method=GET}

providerlimitcounters

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=providerlimitcounters, id=256266346, relatedKey=MEM12345, relatedId=456719800, method=GET}

2017/03/02 13:22:12; …​ ; {keyword=ACCESS, user=JONES, resource=providerlimitcounters, id=256266356, method=GET}

regimecounters

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=regimecounters, id=256266366, relatedKey=MEM12345, relatedId=456719800, method=GET}

2017/03/02 13:22:12; …​ ; {keyword=ACCESS, user=JONES, resource=regimecounters, id=256266376, relatedKey=FAM12345, method=GET}

regimeconsumptions

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=regimeconsumptions, id=256266386, relatedKey=MEM12345, relatedId=456719800, method=GET}

Adjudication Cases

This example shows how adjudication cases are logged. The audit entry logs the case or episode ID, the related member information, and type of the access method used.

adjudicationcases

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=adjudicationcases, id=256266396, relatedKey=MEM12345, relatedId=456719800, method=GET}

Episodes

This example shows how episodes are logged. The audit entry logs the episodes ID, the related member details and the access method used.

episodes

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=episodes, id=256266436, relatedKey=MEM12345, relatedId=456719800, method=GET}

Policy Products and Families

This example shows the audit log entries for policy products and policy families. Each entry logs the accessed resource, the member details, and the action performed.

policyproducts

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=policyproducts, id=256266536, relatedKey=MEM12345, relatedId=456719800, method=GET}

policyfamilies

2017/03/01 15:56:02; …​ ; {keyword=ACCESS, user=JONES, resource=policyfamilies, id=256266636, relatedKey=MEM12345, relatedId=456719800, method=GET}

In part 5, the code of the relation or insurable object is logged instead of the code of the family.

Base Path: http://nddoc01.us.oracle.com:8080/policies/main/allinone/security/user-access/resource-auditing.html

Access to the Generic Audit API is also audited. Each request to retrieve audit data generates a single resource audit log entry as part of the standard PHI/PII resource auditing framework.