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.
Oracle released their latest version of Argus Safety Suite 7.0. The biggest highlight of this release is the “Multi-Tenancy”. This comes very handy for organizations that manage patient safety on behalf of more than one sponsor. This is being dubbed as a ‘CRO Release‘ for obvious reasons. However, another set of service providers that could benefit from this is the Technology Service Providers (TSPs).
Leveraging Argus 7.0, CRO and TSP organizations can host one instance of the application (not considering the various development, test, validation, training environments required) and provide technology and functional services to multiple organizations. The software comes with all bells and whistles required for it to be regulatory compliant as well as keeps the data clean so there is no compromise of patient information and critical safety information. The biggest advantage is the feature set that will enable the CRO/TSP organizations manage the configuration required for each organization separate but at the same time enable them to be able to jump start a new organization’s configuration by leveraging configuration settings of an existing organization.
The diagram depicts a simplistic view of how this works. Please note that it does not include all the components of Argus system as well as the network elements required to ensure connectivity between the CRO/TSP to the sponsor organization. Essentially multiple sponsors will be able to connect to the Argus application through a custom/standard portal setup by the CRO/TSP.
In case of CROs, their internal staff viz. Admins, Data Entry, QA, and Medical Review personnel (depending on requested workflow by the sponsor or the CROs SOPs) would manage the cases. In case of TSPs, the Implementation (installation, configuration and support) and Hosting services could be provided by them while the sponsor manages the case processing bit.
Other enhancements to Argus Insight, Argus J and another new tool to manage Operational Analytics are slated for release throughout this year. In terms of upgrades, it comes with provision to upgrade from 6.0 and 6.0.1. However, for customers on prior versions, they would have to follow the step-by-step upgrade path till version 6 and then upgrade to 7.0.
If you need more details please write to me.