Skip to main content

Data Audit Trail

Medical Information Cloud Inquiry Management offers several features around tracking changes to data within your instance over time. These features cover changes at the record-level in addition to field-level changes. These features are not meant as a replacement for native functionalities available on the Salesforce platform, such as Shield; rather, they are intended to supplement and enhance those capabilities.

When implementing features and configuring to meet requirements around tracking data changes over time, it is important to consider all available features (Salesforce and Medical Information Cloud Inquiry Management) and determine the right mix to solve your requirements holistically.

Record-level event audit

Record-level events are those events that pertain to an entire record. Example events include delete, update, and insert. These events apply to an entire record and are not specific to a single field.

Delete tracking

Medical Information Cloud Inquiry Management offers an audit trail of records that have been deleted within the system. This feature is auto-enabled for Medical Information Cloud Inquiry Management objects and does not require additional configuration to enable.

Supported objects

Tracking is available on the following core Medical Information Cloud Inquiry Management objects:

  • Account

  • Adverse Event

  • AE Drug History

  • AE Drug Information

  • AE Medical History

  • AE Primary Source

  • AE Reaction

  • AE Result

  • Affiliation

  • Case (Interaction)

  • Contact Information

  • Content Document**

  • Content Document Link**

  • Data Change Request

  • Data Change Request Line

  • Email Message**

  • Fulfillment

  • Inbound Form

  • Product

  • Product Quality Complaint

  • Request

  • Request Document

  • Request Fulfillment

** Only tracked if related to one of the following Medical Information Cloud Inquiry Management objects

Audit trail details

Each time a record of one of the above object types is deleted from the system, the following information is captured within the Deleted_Record_Audit_Log Big Object within Medical Information Cloud Inquiry Management.

Field

Description

Event Details

Optional field that contains additional information surrounding the event when supplied.

Object Type

The API name of the object type of the record that was deleted (e.g., MED_Request__c).

Occurred At

The date and time the record was deleted.

Occurred On

The date the record was deleted.

Origin

The cause or source of the record deletion (if available). For example, Anonymization Service.

Parent ID

In cases where a record was deleted due to a cascading action, this field contains the record ID of the originally deleted record that caused the current record to be deleted.

Performed By

A lookup to the User that performed the delete (when available). In rare cases, a delete may be the result of a process that runs as an ‘Automated Process User’ that does not have a corresponding User record to attach to. In those scenarios, the name of the user will be specified in the Performed By ID field.

Performed By ID

The ID of the user that performed the delete, or the name of the system user that performed the delete.

Record ID

The ID of the record that was deleted.

Transaction ID

A UUID v4 ID for the transaction in which the delete occurred. All records deleted within a given context will share the same Transaction ID.

Type

The type of transaction that took place (e.g., Delete).

Extending Record Audit Trail

Medical Information Cloud Inquiry Management offers two ways in which the Record Audit Trail functionality may be extended:

  • Including change events from custom objects

  • Subscribe to change events published for native Medical Information Cloud Inquiry Management objects to apply custom treatments of record change events

Tracking record events on custom objects

Out of the box, this system is pre-configured for the majority of objects relevant to Medical Information Cloud Inquiry Management. For customers who have created custom objects within their Medical Information Cloud Inquiry Management instance, this feature can be extended to support those objects.

To extend delete tracking to a custom object, customers simply need to fire instances of the Change Event custom platform event (mvn__Change_Event__e). Platform events can be fired within Apex classes and triggers in a variety of scenarios. For additional information on platform events, visit Salesforce's documentation.

Change Event platform event

The following table contains the fields present within the Change Event platform event (mvn__Change_Event__e).

Field API Name

Required

Description

mvn__Error_Handler_Class__c

No

An optional apex class API name to override how errors are to be handled. Reference the custom error handling section below for additional details.

mvn__Event_Details__c

No

Any additional details surrounding the event that need to be captured that do not fit into a discrete field.

mvn__Occurred_At__c

Yes

The date and time the record event occurred.

mvn__Origin__c

No

The source or origin of the event such as an integration or automated process.

mvn__Parent_Id__c

No

In the event a given event is the result of a cascading operation the Parent ID is meant to capture the ID of the record that triggered a given event.

mvn__Performed_By_Id__c

Yes

The ID of the User that performed the record event.

mvn__Record_Id__c

Yes

The ID of the record against which the event occurred.

mvn__Object_Type__c

Yes

The type of the object against which the event occurred.

mvn__Transaction_Id__c

Yes

The ID of a transaction that a given event occurred within. Events that occur in the same context should share a common transaction ID. When publishing events a constants class has been provided with a generated UUID v4 that may be used as a transaction ID (see mvn__AuditTrailConstants.transactionGUID).

mvn__Type__c

Yes

The type of event that has occurred. The allowed values for this field are as follows: Delete, Create, Update, Undelete, Viewed, Downloaded. When publishing events a constants class has been provided with an ENUM to guide customers in the selection of the appropriate value (see mvn__AuditTrailConstants.EventType).

Field-level event audit

Field-level events are changes made to a specific field or attribute on a given record (e.g., First Name vs. Account).

Change tracking

Medical Information Cloud Inquiry Management now offers an audit trail of fields that have had a change in value as a result of an insert or update. This feature is not enabled by default for Medical Information Cloud Inquiry Management objects and does require additional configuration to enable. Value changes made to tracked fields will be logged to Field_Update_Audit_Log__b Big Object within Medical Information Cloud Inquiry Management.

This feature is intended to supplement the native Salesforce change tracking functionalities made available on the Salesforce platform. This is, in part, to ensure available data storage capacity is consumed judiciously as this feature has the potential to generate high data volumes in scenarios where fields that are subjected to high entropy are tracked. Customers should consider data storage consumption when determining their holistic implementation of field change tracking.

Supported objects

As stated above, no fields are enabled for change tracking out of the box. That said, the necessary traps (Apex triggers) are in place for most core Medical Information Cloud Inquiry Management objects such that once fields are enabled for change tracking the system will behave as expected. For information on how to extend this functionality beyond the core Medical Information Cloud Inquiry Management objects, visit Extending Field Audit Trail.

Field tracking is available on the following core Medical Information Cloud Inquiry Management objects:

  • Account

  • Adverse Event

  • AE Drug History

  • AE Drug Information

  • AE Medical History

  • AE Primary Source

  • AE Reaction

  • AE Result

  • Affiliation

  • Case (Interaction)

  • Contact Information

  • Fulfillment

  • Inbound Form

  • Product

  • Product Quality Complaint

  • Request

Supported field types

The following types of fields are supported within the field change tracking:

  • Currency

  • Date

  • Datetime

  • Multi-select Picklist

  • Percent

  • Text (includes all variants of text area / long text fields)

  • Time

Note

Medical Information Cloud Inquiry Management attempts to convert field types not explicitly listed above by attempting to retrieve a value via String.valueOf(<field in question>).

Audit trail details

Each time a record of one of the above object types has a tracked field that undergoes an update, the following information is captured within the Field_Update_Audit_Log__b Big Object within Medical Information Cloud Inquiry Management.

Field

Description

After Value

The new value of the field (post update).

Before Value

The original value of the field (pre-update).

Data Sensitivity

A classification of data sensitivity, largely for reporting purposes. Available values are Not Sensitive, PII, and PHI.

Event Details

Optional field that contains additional information surrounding the event when supplied.

Field Name

The API name of the field that was updated.

Object Type

The API name of the object type the update occurred against.

Occurred At

The date and time of the update.

Origin

The cause or source of the record deletion (if available). For example, Anonymization Service.

Performed By

A lookup to the User record that performed the update (if available).

Performed By ID

The ID of the User that performed the delete, or the name of the system user that performed the delete.

Protected Value

Indicator that dictates whether before and after values are captured.

Record ID

The ID of the record that was updated.

Transaction ID

A UUID v4 ID for the transaction in which the delete occurred. All records deleted within a given context will share the same Transaction ID.

Enabling fields for change tracking

All configurations to enable fields for change tracking are made on the Field Audit Settings custom metadata type. To enable a field on a supported object (see list above for supported objects), simply create an entry in the custom metadata type specifying the following:

Field

Description

Capture Values

A boolean to indicate whether before and after values should be captured.

Data Sensitivity

A classification to indicate how sensitive a given field is.

Field Name

The API name of the field to be tracked.

Object Type

The API name of the object on which the field to be tracked resides.

Extending Field Audit Trail

Medical Information Cloud Inquiry Management offers two ways in which the Field Audit Trail functionality may be extended:

  • Include field change events on objects not supported natively

  • Subscribe to field change events published for native Medical Information Cloud Inquiry Management objects to apply custom treatments of field change events

Tracking field changes on custom objects

Out of the box, this system is pre-configured for the majority of objects relevant to Medical Information Cloud Inquiry Management. For customers that have created custom objects within their Medical Information Cloud Inquiry Management instance, this feature can be extended to support those objects, or native Salesforce objects that are not supported natively.

To extend field change tracking to an unsupported object, customers simply need to fire instances of the Field Change Event custom platform event (mvn__Field_Change_Event__e). Platform events can be fired within Apex classes and triggers in a variety of scenarios. For additional information on platform events, please refer to Salesforce documentation.

Field Change Event platform event

The following table contains the fields present within the Change Event platform event (mvn__Field_Change_Event__e).

Field API Name

Required

Description

mvn__After_Value__c

No

The new value of the field (post-update).

mvn__Before_Value__c

No

The original value of the field (pre-update).

mvn__Data_Sensitivity__c

No

A sensitivity classification for the field.

mvn__Error_Handler_Class__c

No

An optional apex class API name to override how errors are to be handled. Reference the custom error handling section below for additional details.

mvn__Event_Details__c

No

Any additional details surrounding the event that need to be captured that do not fit into a discrete field.

mvn__Field_Name__c

Yes

The API name of the field that was updated.

mvn__Object_Type__c

Yes

The type of the object against which the event occurred.

mvn__Occurred_At__c

Yes

The date and time the record event occurred.

mvn__Origin__c

No

The source or origin of the event such as an integration or automated process.

mvn__Performed_By_Id__c

Yes

The id of the User that performed the record event.

mvn__Protected_Value__c

Yes

Indicates whether before and after values should be captured.

mvn__Record_Id__c

Yes

The id of the record against which the event occurred.

mvn__Transaction_Id__c

Yes

The id of a transaction that a given event occurred within. Events that occur in the same context should share a common transaction id. When publishing events a constants class has been provided with a generated UUID v4 that may be used as a transaction id (see mvn__AuditTrailConstants.transactionGUID).

Expose field change data in the Lightning user interface

For component implementation considerations, visit Field Audit Trail Related List.

Custom error handling

When errors occur in the handling of published Field Change Events, a default treatment is applied to gracefully handle and log any errors that may have occurred. By default, this information will be saved to the Debug Logs (mvn__Debug_Log__c) object. Visit Debug logs.

Customers who would like to apply a different treatment to change event processing errors may implement an interface that can apply any treatment supported by the technologies made available by the Salesforce platform. Custom handlers should implement the Callable interface exposed on the Salesforce platform, providing support for the ‘handleErrors’ action.

The code block below illustrates the critical portion of implementing a custom error handler.

public with sharing class CustomAuditErrorHdlr implements Callable {
    /* 
    * @description Callable implementation to be the default ErrorHdlr for RecordAuditEventHdlr     
    * @param action Only accepts a value of 'handleErrors'     
    * @param args   Only accepts a Map<String,Object> that should include a single key of 'errors' with a value containing a List<String>     
    */
    public Object call(String action, Map<String, Object> args) {
        switch on action {
            when 'handleErrors' { ...

Salesforce Big Objects

Big objects are a special type of data store made available on the Salesforce platform that is designed to support large data volumes. Out of the box, up to 1 million Big Object records may be stored. Additional storage capacity can be purchased from Salesforce. Additional details on Big Objects can be found within the Salesforce documentation.

Data security considerations

Keep these considerations in mind when working with Komodo Health's Audit Trail:

  • By default, the native System Administrator profile will grant access to all audit records available in the system. As a result, customers are encouraged to review all individuals who have been granted such access are valid, and if necessary, implement the necessary changes to fine-tune who can see this information.

  • Komodo Health Audit Trail tracks and displays encrypted data when appropriate. However, Salesforce Big Objects are not encryptable by Salesforce, so data is stored unencrypted even if the field tracked was encrypted.