New Audit Log System for OpenMRS: Seeking Feedback and Suggestions

Development
1

Hi Everyone,

Ensuring robust audit capabilities is essential for a platform like OpenMRS. While we have historically relied on the openmrs-module-auditlog, it has become outdated and no longer compatible with the latest versions of OpenMRS.

To address this, we are now developing a new and modern audit log system using Hibernate Envers.

There are two main phases in this

  1. Enable Hibernate Envers audit logging on the OpenMRS CORE.
  2. Create a new module to display audit logs to the user.

We have already completed the first phase. For more details on our implementation, you can explore the resources below:

We have begun developing the module UI, and I started a simple prototype. Until we establish an official OpenMRS GitHub repository, you can view the progress on my personal GitHub repo: openmrs-module-auditlog.ui

We are planning to implement the following features in this module:

  • List all changes made to a selected table.

Users will be able to select a table for which they want to view audit details (e.g., Patient tables). The module will then display basic information about the changes that occurred to entities within that table, presented in a format similar to the table shown below:

Screenshot from 2024-07-04 20-43-55
Screenshot from 2024-07-04 20-43-55940×168 5.55 KB

Users can click on a specific row to access more detailed information about a change.

  • List all the revisions of an entity

Users will have the ability to select a table and an entity within that table. The module will then display all revisions associated with that entity. I’ve designed a basic format for this display, but I believe it still needs significant improvement.

Screenshot from 2024-07-04 20-56-19

  • Search and filter audits

Users should be able to search and filter audit records based on parameters like the individual who made changes and the timeframe. For example:

All changes made by John between July 4, 2024, and August 4, 2024.

We are eager to hear your feedback, suggestions for improvements, or ideas for additional features that could enhance this module.

cc: @dkayiwa, @grace

3 Likes
2

This is great. Audit logging capabilities are often requested in formal spec documents for EMR/EHRs. A big gap to fill there. :clap:

3 Likes
3

@wikumc, I would not display this as tables, because that would be unnecessarily exposing internal database schema details to the user. I would use domain entities like patients, encounters, observations, visits, concepts, etc. Then it is the responsibility of the module to know which tables to join, for the requested information.

1 Like
4

Glad to see that someone is steering the switch to envers, @dkayiwa I recall there was a design call where we discussed the need to switch to envers, where did that end? Is it related to the work @wikumc is doing? If not, let’s try not duplicate efforts.

5

@dkayiwa, it will not display table names. I’ve decided to use code that extracts classes with the @Audited annotation, so we’ll only be displaying the class names.

6

Can we come up with a better module id and name? It would also be nice for the github repo name to match it.

7

Possible names: openmrs-module-audit or openmrs-module-auditing

8

How about openmrs-module-auditlogui?

9

@wikumc when some one wants to see the audit log of, for example, a patient, we should shield them from having to know the corresponding java classes that store patient data (Person, Patient, PersonName, PersonAddress, PatientIdentifier, etc). Do you see how complicated it can be for them to know all thoses classes?

10

@wikumc please see this convo on Slack and please attend the Design Office Hours to get insights as to how to present this data to the users.

1 Like
11

This can’t be, the UI will be provided through an ESM of sorts, your module is a backend module, right?

12

We have enabled auditing in OpenMRS CORE using Hibernate Envers, which captures and stores changes made to the database in dedicated audit tables.

The primary objective of this new module is to offer a platform for administrators to access and review these audit records in a structured and meaningful format. Essentially, this module is a user interface allowing admins to view and interact with the audit data.

13

The topic of the thread is misleading, all along I thought this was about the backend.

Out of curiosity, I see that in core there is a way to enable envers, this would enable auditing for all tables which most likely implementations would not want, was a way provided to configure specific tables rather than all tables?

14

@wyclif, the module is mainly backend-oriented, including controllers and services for audit logs.

Right now, Hibernate Envers audits anything with an @Audited annotation and doesn’t let us pick and choose tables to audit. However, I believe we might be able to do selective auditing through the OpenmrsRevisionEntityListener class. I think it’s possible, but I’m not 100% sure yet. Definitely needs some testing to see if we can make it work.

15

@wikumc ok so what you need is a web REST API to interact with all this, in order for an upcoming ESM to leverage it.

Looks like FHIR will provide what you need… in the future (unfortunately), see AuditEvent - FHIR v6.0.0-cibuild

So should we develop REST endpoints in the REST WS module, I would suggest to get to something close to what this upcoming FHIR API will look like.

@ibacher , thoughts?

16

Well, I’m not sure how useful this feature is going to be to users if the application is hardcoded to decide what is audited or not, or are all tables audited? Because the question becomes, what is audited out of the box? I would imagine mutable data entities only are audited and no metadata is audited since it is expected to be managed outside of OpenMRS.

Envers can be a challenge to use in a modular application like OpenMRS where you expect different entity behaviors. In my opinion this could have been implemented first in a module to allow it to grow at its own pace, with a goal of moving it into core at a later point after it matures.

2 Likes
17

@mksd We are planning to develop endpoints to access the audit data. Additionally, we intend to design a user interface for those not using O3. We would love to hear your feedback on the essential features and functionalities of this UI.

18

Could you give us some background about this work? Who’s initiating it, what are the use cases, are there specific requirements that are being followed, etc?

1 Like
19

AuditEvent has been part of FHIR since the initial draft version. It’s there, we can use it.

That said, my biggest issue with the current iteration of the audit system is that it only audits create, update, or delete events, but from the perspective of reviewing actions done in an EMR, users will care almost exclusively about read events, i.e., did person X look at the record for patient Y? Which patients has X looked at? Who has reviewed the record for patient Y?

2 Likes
20

That’s a good catch @ibacher