Transition to Oracle Argus Safety – Key Considerations – Part 2
In my previous post titled “Transition to Oracle Argus Safety – Key Considerations – Part 1” I summarized the key considerations for Transition to Oracle Argus Safety. The Infographic included in the previous post, summarizes the considerations across the Business Process, Business Support and Application Support areas.
In this post, I will outline the considerations in Single Case Handling. This is one of the most resource intensive and critical functions of a safety organization. This is one function that cannot be interrupted, despite transition to a new tool/system, as it his many implications on the sponsor organization as well as on the patients.
- Business Process Services:
- Process Optimization: This is one of the aspects of the safety organization that will be impacted immediately. The business teams processing the cases would have reached their peak performance within the current environment. Introducing Argus will impact the team as they have to learn new tool and also readjust to a process that most likely was reengineered
- Case Receipt Automation: Many organizations would have automated the Case Intake process. The process of automation and any tools associated with it would have to be reengineered to leverage Argus’ Intake capabilities instead
- QA, Metrics & Best Practices: The quality assurance of the single case processing, the performance metrics associated with it and the best practices established over the course of time will all be impacted and probably take a dip with the introduction of Argus. This has to do more with the change in itself rather than the functions/features/capabilities of Argus tool
- Business Support:
- Access Management: The users need to be configured in the new system. Also, if any new users are being on boarded as part of consolidation then this will have to be accounted part as part of access management
- Partner Support: The Safety organization will have established relationships with CRO partners. These partners need to be supported during the transition. This might also mean reengineering some of the Intake processes, tools and systems. If Argus Affiliate module is being leveraged for capturing AEs from the affiliates, this could add additional entity to the support organization from a configuration as well as help desk support perspective.
- Report Distribution: The established channels of distribution of expedited reports to regulators will be impacted with the introduction of Argus. This might mean retesting any electronic E2B report submission channels. The review, approval and submission of reports may need to be configured using Argus and Argus Interchange modules.
- Application Support:
- Workflow Configuration: The Case Processing workflow need to be reconfigured. For large organizations this is usually a complex task as the automated routing of cases to the right groups/personnel is key to efficient processing. If a global consolidation is undertaken as part of the transition, this task would become even more complex.
- E2B and Reconciliation: The established process and tools for collection and/or distribution of safety data/reports to/from partners should be reengineered with the inroduction of Argus. Also, the safety case reconsiliation that happens between the clinical and safety systems will be impacted and should be reengineered and automated to account for changes due to Argus
- Distribution: As mentioned in the Business Support, the reporting process will be reconfigured, which will necessitate a reengineering of distribution process.
In the next part, we will look at additional considerations from an Aggregate Reporting perspective.