Have you ever wondered why Argus Safety functionalities you have been using for months or years suddenly started behaving as though someone secretly changed your configuration? Everyone, at some point, feels as though their system has become its own evil twin.
Let’s dig down into some common reasons why Argus Safety begins, without warning, to behave badly:
- Data Migration: This is an all too common scenario where data from a legacy system or an acquisition is migrated into your perfect Argus world. The most common cause is that the data you migrated from the legacy system didn’t correctly map to its rightful space in Argus, and now, it isn’t going to behave as expected. Most occurrences after data migration can be prevented with a robust migration plan, correct system configuration, and early testing to ensure that the migrated data doesn’t have unanticipated downstream effects. Beware of data that has been migrated multiple times!
- Configuration Changes to the System: We all want the perfect configuration to maximize the utility of our system. Now moving in the direction of utilizing AI, ML, and NLP and RPA technologies, sometimes setting up the configuration without thinking through the scenarios of how the data will respond to your best-intended changes can make a mess. For example, Harold wants to clean up the old site configuration and ensure all case processors can view all cases. Just inactivating those unwanted site configurations and placing all users into one bucket has ramifications at the case level. Most likely, those issues won’t appear until a critical moment and will take hours to unravel. It’s good practice to have someone in your group who knows the true functionality and logic of Argus to ask before you tidy up.
- Non-Technical Glitches: Not to take away from the fantastic mysteries of technology, remember you are working with a software package with its own hard-coded logic. We humans (at least most of us) are not hardcoded in how we think and process. The software must be to some extent. The most significant cause of wonky data? Not having the right case processing guidance to support the configuration of your system. That includes what you can and cannot do within the system. Putting together case processing guidelines based on how your Argus Safety is configured seems like a logical place to start, but we often miss the horses looking for zebras. When data starts to take an unexpected turn or expected functionality begins to not function, it’s time to dig in and look for the cause. Look at your case processing guidelines or coding conventions. A well thought out guidance; especially if you outsource, is critical to the success and efficiency of your case processing. It also reduces the number of aberrant behaviors.
Here are some things that make case processing guidance or work instructions difficult; leads to stress, frustration, and non-compliance:
- Multiple embedded guidance within one document: The worst-case processing guidance does not consider the Argus safety database and has numerous embedded references within the document requiring the user to click multiple times to find the right answer. Rather than embedding a document within a document, make the available information upfront with the corresponding Argus Safety screenshots. Break it into logical areas of your workflow, i.e., a section on “Serious AE Case Processing,” not forgetting the process but the timelines.
- Outdated code processing or medical review coding instructions: After any changes are made to the Argus Safety database, the case processing documents should be reviewed and updated. Nothing is more frustrating than coming to a new screen in Argus (i.e., after patching), and the user doesn’t know what to do with the data fields. Supported versions of Argus Safety are designed to be flexible enough to accommodate regulatory changes. This is usually done by applying a patch to the system under your SDLC procedures and testing.
Now… to information about the importance of Saving a Case in Argus!
Let’s talk about one specific scenario of what cannot be done in Argus when manually scheduling an expedited report.
You scheduled an expedited report; it’s a short-dated case and must be submitted now. You noticed that you chose—the wrong product license during scheduling. Common sense tells you (without looking at your guidance document to delete the report and schedule a new one.
After scheduling a new report with correct parameters, the scheduled report shows an incorrect version number. The report is supposed to be Follow-up #1; however, it shows Follow-up #2 on the regulatory reports tab.
This makes no sense looking at the screen. Human logic says to fix it. You delete the report and schedule a new one hoping it will show the correct version.
To your surprise, it didn’t fix the problem. It is still scheduling Follow-up#2 instead of Follow-up#1.
What Is This?
Argus Safety expects concrete steps, which sometimes we overlook. E.g., Here you forgot clicking the ‘SAVE’ button after you marked the F/up#1 report for deletion in the beginning. This resulted in a new Follow-up#2 report instead of Follow-up#1.
Look below while you are frustrated and urgently trying to get an expedited report scheduled, notice that the Argus Safety UI did not remove the deleted report entry until you save the case. That’s the reason even re-scheduling the report does not fix the report version in this scenario.
Although the generated report output will print the correct follow-up number (if applicable for the report form type) but the report version number on the user interface is confusing and makes tracking of this case difficult in the future.
What can you do to avoid these types of Argus idiosyncrasies?
Here is where thoroughly reviewing the case processing steps against your actions before proceeding to the next stage can save time and frustration. If not, it becomes challenging to fix these kinds of subtle issues. If you didn’t catch this error and submitted the cases overlooking the wrong version number, it costs more later in the case of life. Although technically feasible to remediate, it’s not a fun job to fix case versions because the case processing guidelines didn’t specify the detail or you didn’t look. Hence, the above attention to useful case guidelines.
We all want to be high performers, but logical steps dictate success:
Do not forget to save the case before/after performing the crucial steps like data entry, report scheduling, report deletion, etc. This will ensure that the next case processing step is performed on the most up-to-date data and not half-processed data, as you noticed in the above example.
We have witnessed our clients’ perplexing situations, their time, and money being spent to understand and fix these issues. So, we recommend having:
- Comprehensive work instructions to capture the details, including small but essential steps such as saving a case. For those who drown in detail, if it’s important to call it out:
- Cautions like ‘DO NOT FORGET TO SAVE THE CASE AFTER DELETING THE REPORT’ at the error-prone steps
- Checklists for tabs in Argus identifying critical case processing steps based on your Argus Safety configuration
- Detailed user guides designed for specific roles and aligned with your PV Operational processes
At the end of the day, best practice is to review your Argus Safety configuration against what is practical for your organization, what is working well vs. where common mistakes are made. Establishing not only case processing guidelines but having an early and thoughtful discussion on the configuration of your system before it becomes out of control is a must for maintaining a well-functioning PV Operations team.
A word on Argus safety configuration: When the user interface (UI) was moved to the front end of Argus, it empowered users to perform basic functions. These changes to the system are captured within the audit trail and make it easier to document any changes to a validated database. What an organization should avoid is designating too many administrator roles to control the configuration changes. Before making a configuration change, look carefully at what the system functionality is and the potential downstream effects. Test thoroughly in your lower environments before implementing it in your production system. If you aren’t sure what the impact is or need assistance with a “Health Check” of your Argus Safety system, please reach out to the PV/Safety Team at Perficient.
