Application Logging

Patient records are managed in the clinical system. Many users access medical documents, clinical orders, medication data etc. at various times, or make changes to the data of the electronic patient record of a patient.

Using Application Logging you can log all accesses (display, change, etc.) to the patient record, as well as specific functions executed on individual objects. The system logs actions of the user or system (events) in the form of Messages, which can then be evaluated by a specially authorized user in the form of Logs.

If you wish to log an object action, you must decide whether this thematically belongs in a patient-related or user-related log in i.s.h.med. Otherwise you should use the SAP basis function for logging.

Note Note

Application logging is a utility which runs in the background - usually temporarily delayed after the actual user interaction. It has no effect on the user’s daily work. The messages and logs created in application logging are only available to specially authorized users.

Asynchronous processing of events triggered by the user can minimize the impairment of the response time caused by application logging. Asynchronous processing means that, in the dialog process which the individual user is operating, the system only executes the checks and actions which are necessary to ensure later processing. Following these checks the system continues the relevant program logic of the application.

End of the note.

The following i.s.h.med applications have logging functionality:

Clinical Orders
Medical Documentation
Medication Orders (Medication component)
Medication Events (Medication component)
Patient Organizer (electronic patient record)
Patient Profile

Implementation Considerations

In order to be able to use application logging correctly and purposefully, you should formulate the questions which should be answered by the logging, before you start to use it.

The log entries (messages) of application logging contain relevant information for answering, for example, the following questions:

Which users have printed the discharge summary of a specific patient?
How did a specific user display a certain document (e.g. PDF display, dialog application)?
Which users used the patient organizer to access the electronic patient record of a certain patient?

You must identify in particular, the patient record objects which should be subject to application logging.

Caution Caution

The introduction of i.s.h.med application logging involves an increased system load. Particularly during periods of high activity, where many users are editing patient records in parallel, application logging programs are processed in addition to the existing programs of the individual applications. You can use a suitable application logging implementation strategy to assess whether your system landscape can cope with this additional system load without problems, or whether bottlenecks (storage or database requirements, updates, processor activity) may occur during individual aspects.

End of the caution.

Recommendation

We therefore recommend that you execute the implementation of application logging in several steps and monitor the system behavior. If bottlenecks or problems do occur, you can therefore quickly revert from the current step to the last functioning settings.

You should particularly monitor the following parameters:

Mean response time per dialog step (system load monitor)
Storage requirements in central memory and on database
Utilization of dialog processes in process overview
Utilization of update processes in process overview and update statistics

End of the recommendation.

At the beginning, configure a logging profile which selectively logs only specific activities. For example, you could log only the printing of discharge summaries. It is also sensible to restrict the logging profile to a manageable number of users.

See Configuring a Logging Profile

Only when this logging functions without impairing the system should you increase the logging configurations and logging profiles by adding new events and users or reducing the filter conditions.

Storage Requirements of Database

As soon as you activate application logging, more storage capacity is required on the database. The size of this extra storage capacity is oriented toward the number of messages which are logged. You should successively increase the number of logged messages in a suitable application logging implementation strategy.

Caution Caution

A message has the data type BAL_S_MSG. This structure has a total of approximately 600 characters. For each message approximately 1200 bytes (1.2 kByte) of storage is required.

You must multiply this 1.2 kByte with the number of messages per period, in order to determine the overall storage requirements per period.

You should therefore note that, due to the considerable resulting data quantities, you should not use application logging non-specifically.

End of the caution.

You can archive messages in order to archive and then delete expired logs, so that the storage requirements of the database are kept constant on a long-term basis.

Prerequisites

Application logging is available to you if you have activated the business function Clinical System Enhanced Documentation Processes (ISHMED_EDP).

In order to be able to execute application logging, you must execute the necessary setup functions.

See Setup Functions for Application Logging

Process

If a user or the system executes an action on a specific object of the electronic patient record (e.g. displays a document, etc.), the system will create a message in application logging. In application logging, this message describes the action this user or the system executed on the electronic patient record object.
In the message text the system uses message variable to transfer information on the object, the user and the event. The system uses a sequence of message variables and field labels to write the data in the message. This data is also always available in structured form in the context. It is therefore also possible to filter or sort these columns.

Example
The message for creating a clinical order reads:

Clinical Order: 2005001201(001); User: MUSTER; Event: Created; 20.04.2006 11:06

End of the example.

For each message the system also stores the context, which contains further information on the document (from which program the document was displayed, etc.).

You can customer-specifically enhance the context of the messages. As standard the system will store a specific set of information as the context of the messages. You can also enhance the structure RN1_ALENTRY_CONTEXT using an append structure, to add further information to the context of the messages (you can enhance the context by up to 50 characters).

Furthermore the enhancement spot N1_ALENTRY_FINALIZE with the FINALIZE_ALENTRY method is also available. When a new message is logged, the system calls this enhancement spot. You can use the IR_ALENTRY->SET_CONTEXT method to fill your customer-specific context information. The system will automatically display the customer/specific context information in the technical information and in the columns of the output table for messages.

Note

The context information is technically limited to 256 characters (standard plus customer/specific append structure) and cannot be redesigned in any way. The system cannot therefore save the entire status of a document at the time when it is displayed. You therefore cannot subsequently determine which information a specific user received when the document was displayed.

The system saves the created messages in the structure BAL_S_MSG.

End of the note.
You can use the Evaluate Logs function (transaction N1ALEVAL) to evaluate the created application logging messages in patient-related or user-related form.
See Evaluate Logged Messages

Example

Examples of application logging usage scenarios:

You use application logging to evaluate the internally configured authorization system in i.s.h.med. You can use application logging to execute evaluations which should determined that users can only access patient record objects for which they are actually authorized.
In case of data misuse you can execute improved evaluations which can help to determine the cause of the misuse. You can create, for example, a list of all users who executed actions with a specific document or who generally accessed a patient's patient record.