New Audit Log System for OpenMRS: Seeking Feedback and Suggestions

Development
21

100% agreed, this is very important as spec for an audit system.

1 Like
22

@ibacher how much is this important? Are there any organizations that are eager to use this functionality immediately?

@mksd I see in your ozone pro plan, that you are offering audit logging. How is it related to this discussion?

Bed management in RefApp
23

As we routinely see in EMR/EHR tenders, the ability to audit the usage of an EMR system is a hard requirement. As a vendor proposing OpenMRS as the EMR solution, I would say that I would love to tick that box with confidence.

This is slightly different and is a bit of a plan B. Ozone Proā€™s monitoring platform provides support for auditing through centralising logs of all Ozone apps running in a given distribution. Still, it doesnā€™t mean that itā€™s ok for the EMR system app itself (OpenMRS for instance) to not provide a proper audit system.

2 Likes
24

HI @wikumc I just wanted to follow up on the Audit Log. There have been a few discussions on Slack around this important feature, and we have also submitted a project idea for GSoC 2026 related to a native frontend for O3.

I wanted to confirm whether the backend part is production-ready and available in the current version. Iā€™m asking because we might need to accelerate the frontend work, as weā€™d ideally like to have it completed by the end of March 2026 (whereas GSoC usually concludes later in the year).

Nevertheless, I mainly wanted to clarify which parts are currently considered production-ready and how can we help to sped up the process?

Thanks! cc: @olewandowski @pwargulak

25

@alebiedzinsk Thanks for your interest in this. Weā€™ve enabled Hibernate Envers for auditing, which allows us to track:

  • record creation
  • modifications
  • deletions

For a typical application, that level of auditing is often enough. But for an EMR, we also need to audit additional events such as:

  1. system start/stop
  2. user login/logout
  3. session timeouts
  4. account lockouts
  5. patient record views

Envers alone wonā€™t cover those, so weā€™ll need to implement them in future releases. Right now, no one is actively working on these items, and I was planning to propose this as a GSoC project.

That said, if the current auditing capabilities are sufficient for your use case, I think you can already kickstart the O3 UI. The module exposes REST endpoints you can use. Once you start developing the UI, if you identify missing features or any changes needed, we can implement those on the backend.

cc: @dkayiwa, @ibacher

2 Likes
26

@alebiedzinski thanks for being interested in this feature and to move things forward faster. As @wikumc said, the module can serve the basic of application auditing of CUD operations, however some events are still be implemented. Feel free to kick start the o3 implementation or better still we can sync up to start that, as we progress anything missing from the backend side we handle that on the go. For the missing events auditing in question, we will propose that as a topic for GSoC 2026.

27

Thanks for your replies @wikumc @nsalifu ! Weā€™ll check on our side whether thatā€™s enough to kick-start the FE for the Audit Trail. Is there any further or more detailed description of what would be proposed for GSoC 2026? Or would you like to cover the five missing events that were mentioned?

If this were to be qualified as part of the GSoC 2026 program (BE part), what would be the expected timeline for these changes to be released to the core solution?

1 Like
28

@alebiedzinski we will share what we hope will be part of it for gsoc 2026 soon. I think that will help us all come up with solid requirements of the audit trail and a proper timeline.

29

The events I shared are just a few of the ones we eventually need in the system. In reality, there are around 20 events that EHRs in the US are required to audit, such as:

  1. system start/stop
  2. user login/logout
  3. session timeout
  4. account lockout
  5. patient record created/viewed/updated/deleted
  6. scheduling
  7. queries
  8. orders
  9. authentication failures
  10. signature creation/validation
  11. PHI export (for example, printing)
  12. PHI import
  13. security-related admin events
  14. backup and restore
  15. system upgrades and changes
  16. code and knowledge base updates
  17. system date and time changes
  18. data archival and restore
  19. maintenance session start/end

Even if we canā€™t cover all of these, we should at least try to audit the most important ones. We wonā€™t get a final deliverable from a GSoC project until the end of the year, but weā€™re happy to help with any issues you run into while building the frontend.

30

Got it - thank you both !

@wikumc Iā€™m a bit confused - is the module capable to audit basic CUD operations on production? Based on what you guys described above, it seems so. However, thereā€™s a ticket raised at OpenMRS JIRA, which states that solution is not ready for the production environment - Jira . I saw you created a PR but it hasnā€™t been merged so far. That being said - is it stable and can be used or not? @ibacher What are your thoughts? Weā€™ll also review it on our side.

31

Oh yeah, I completely forgot about that PR. We definitely need to get that merged :slightly_smiling_face:

32

@wikumc I wanted to follow up here. Whatā€™s the status of this PR? This is rather important for us as we want to start some work related to Audit Trail FE. When we can expect it to be reviewed and merged? We can review it and provide feedback it that would sped up the process!

@ibacher @dkayiwa @pwargulak