1. Configuration to the Gateway System via the Web-Interface
We were not able to understand what changes were made in the web interface via the OOB Audit Log. In addition, there was no way to add a reason for change. Are there any best practices for logging changes, understand what has changed (new value, value before) and a option to add a reason?
2. Project which is on the gateway via the Designer
There are also not a lot of information in the audit log regarding the project itself. Is there a option to at least ask for a reason when saving the project?
3. Perspective / Vision Actions
This should be okay, as it is possible to add custimized Audit Log columns and a pop-up to add a reason for a change.
Are there any changes coming in an upcoming version (8.3) to improve the deployment of configurations/projects and an audit/event log?
Yes, I have been involved in projects with Pharma customers.
For auditing you really have to get with the client on what exactly they want to see.
For this we typically use a report in report builder to visualize and allow a pdf of the audits to be printed, but in terms of the reasons that is going to have to be kind of custom. Our customer has a work order system they use to track changes that would be made to the production environment and then a QA session with a dev gateway, and then those changes are made on the production environment. They go through the audits on a regular basis to see if there are any changes made outside of a work order time frame.
In general I think you are going to have to create some sort of work order/change log that the people changing the items would need to fill out. This can obviously be done with the system.util.audit function when they submit the form.
Another option would be to create a table in the database that holds your AUDIT_EVENTS table, and have that table be a reason table using the AUDIT_EVENTS_ID column to track the filled out reasons. You could set it up so that it shows a flag if there are project save actions made that do not have reasons associated in your other table
Something else to think about in pharma is the User requirements specifications that your client will want to be put in place and making sure these actions line up with those URSs and you can provide meaningful documentation to allow for fluid use of the system.
Hope this was helpful. Pharma can be a bit of bear if you aren't used to it. Ignition lends its flexibility well to some of their more rigid requirements, but can also be a bit of a headache when you run into some of the FDA requirements (If it is USA) for things like no data duplication etc.
Using change management and referring to the time a change was done in Ignition might be a light solution, but I'm not sure if this will convince every auditor, as you don't see what has been changed. We can add an additional version control for configurations, but beside the fact that managing this in three different system (Change Management, Version Control and Ignition itself) managing this sounds complex and finding the right information during an audit quite stressfull. E.g. when somebody changed a tag, removed the history or something like this will directly impact FDA requirements and I still can't see a good way to track this at the moment.
There might be ways to do this, but we need to further think about the consequences in operations.
When it comes to a project, I agree. We can add our own audit entries, incl. required required reasons for a change at a production line.
