The following transactions (events) are logged in the transaction log:

• Login and logout - including rejected login attempts

• Organization administration: Set up organization hierarchy, create / update / delete / undelete organizational units, import / export.

• User administration: create / update / delete employees and employee users. Remember that an employee user is an employee having a user name.

  Note
  An application may be configured to allow patients to login. In this case the user may be a logged in patient. There is no need for managing patient users - when a patient is created, that patient may log in.

• Patient administration: create / read / update / delete / undelete / merge patients.

• Records (form instances): create / read / update / delete / move / copy records.

• Misc. operations: running reports, querying the log, etc.

Note
Logging events on Patient and Record objects is more comprehensive than the other types. Because of the personal and sensitive nature of patient data, reads are logged for Patient and Record objects. Reads are not logged for any other types of objects.

Note

TOPICA defines a fixed list of action types (an enumeration). That is, applications that implement applications-specific object types and/or actions (e.g. in custom webservices or custom webforms ) cannot extend this list. When such actions should be logged, choose an enumeration value from the defined enumeration that is most resembles the action to be logged, and use the Parameters and/or Description free text fields to specify the custom action.

Note

There are two kinds of deletions: logical and physical. Objects that are logically deleted remain in the database. Therfore it is possible to navigate to the logically deleted objects. Such objects may be "undeleted" and/or physically deleted (if the user has sufficient permission). Patients and organizational units may be logically deleted. Objects that are physically deleted are deleted from the database. Therfore it is NOT possible to navigate to the physically deleted objects. Employees and records (form instances) may only be physically deleted. From the log it is not possible to see directly, whether a deletion was logical or physical - but links to physically deleted objects will most likely cause an error.

Each entry in the transaction log (= row in table LogEntry) has the following information:

Header	Description
DateTime	The date and time, the transaction / event was logged
Action	The type of transaction / event TOPICA defines a fixed list of action types (an enumeration).
User name / full name	Links to the employee user, that initiated the transaction / event.
Patient (logged in)	Link to the logged in patient, that initiated the transaction / event. This column is only visible in the user interface, if the application has been configured to allow log in as patient. Physical deletion of patients will make this link invalid. Each log entry should be linked to EITHER a logged in employee OR a logged in patient. Both should never be set on the same log entry!
Employee	Link to the employee being updated by the transaction / event.
Patient	Link to the patient being read / updated by the transaction / event.  Note Log entries regarding records (form instances) should ALWAYS have a reference to a patient, because each record belongs to a patient.
Organizational unit	Link to the org.unit begin updated by the transaction / event.  Note Log entries regarding patients and records (form instances) do NOT refer to organizational units.
Document reference	Link to document reference begin created / updated by the transaction / event.  Note This refers to document references (or entire documents: BLOBs) stored in the database. Do not confuse this with documents, that are stored in the web server's file system!
Result	Result code for a few select transaction types.
Table / Record	Link to the record (form instance) being read / updated by the transaction / event.  Note Log entries regarding records (form instances) should ALWAYS have a reference to a patient, because each record belongs to a patient.
Parameters	Free text field containing parameters for selected transaction types.
Description	Free text field that may be used for any information relevant for the transaction type.
IP address	The IP address of the web request initiating the transaction.
Sesison GUID	The unique identifier of the session in which the transaction was initiated. Will be empty in situations where a session is not yet created - e.g. when displaying the log in form, and denied login attempts.

The TOPICA Framework contains a page that enables end-users to search the transaction log.

It is possible to start the transaction log search page in different contexts. Setting a specific object in context filters the output rows, so that only log entries regarding the object in context are displayed. The context also has an effect on the columns displayed - columns that are irrelevant in a given context are not displayed. Date/time, type of transcation, and user information is displayed in all contextss.

• No context = on system/database level (initiated from menu item "System / Log"): Only users having the "log read" permission are allowed to query the system level log. No object / row filtering takes place.

• With an organizational unit in context (initiated from sub-menu tab), only the transactions relating to the organizational unit in context are displayed.

• With an employee in context (initiated from sub-menu tab), there are two possibilities:

  • "Reg" will display only those transactions, where the user in context is the registrator (e.g. what objects this user has created/updated).

  • "Adm" will display only those transactions, where the employee in context has been created/updated.

• With a patient in context (initiated from sub-menu tab), only the transactions relating to this particular patient are displayed.

• With a record in context (initiated on the "history" page), only the transactions relating to this particular record are displayed.

Except for when displaying log for a record, the following applies:

• It is possible to filter by date/time interval and/or by transaction type.

  Note
  Entering a time of day value is possible only in versions 4.28 and newer. In version 4.27 and older, only dates may be entered. In version 4.30 and newer, the "From date/time" search criteria has the current date as default value.

• It is possible to filter by transaction type (select from dropdown).

• Per default, newest log entries are displayed at the top.

  It is possible to change the sort order by clicking hyperlinks in the column headers. Click again to toggle between ascending and descending.

• When the search result contains many log entries, paging is applied. Default page size is 20 rows - may be adjusted.

  Caution
  Clearing page size field turns off paging - use with caution! Number of rows returned depends on the filter and user entered search criteria. When thousands of rows are returned, do not turn off paging. Rendering the page with thousands of rows will take a long time!

Information on specific objects displayed in the search result is displayed as hyperlinks. E.g. when displaying a log entry where a record has been read/created/updated, it is possible to click on the record id and navigate to the record in question (this naturally sets both the patient, to which this record belongs, and the record in context).

Note

Objects that are logically deleted remain in the database. Therefore it is possible to navigate from the search log user interface to logically deleted objects. Objects that are physically deleted are deleted from the database. Therfore it is NOT possible to navigate to physically deleted objects (from the search log user interface or otherwise). Clicking a link that refers to a deleted object will probably cause an error.