In lieu of the recent draft guidance issued by FDA on “Providing Regulatory Submissions in Electronic Format — Content of the Risk Evaluation and Mitigation Strategies document Using Structured Product Labeling” earlier this month, I thought of taking a trip down the memory lane to revisit how we got here on REMS.
The following diagram provides a snapshot of the timeline: REMS-Journey
For those keen to understand how REMS documents get converted to SPL elements, you can refer to this presentation on “REMS Standardization via Structured Product Labeling (SPL)” by Adam Kroetsch, Policy and Informatics Advisor, Office of Program and Strategic Analysis, Center for Drug Evaluation and Research from October 5, 2015.
I have talked about REMS in my past blog posts, specifically about “Implementing FDA REMS ETASU Requirements using a BPM Suite“. Feel free to check it out. I will have more to say on this topic in my future blog posts in relation to impact of the new guidance and how to prepare for it.
Oracle Argus Safety is a leading Safety & Pharmacovigilance platform in the market. Oracle has been able to successfully move many sponsors from diverse drug safety platforms it built (Oracle AERS) or acquired (PhaseForwards’ Clintrace and Relsys’ Argus) to Argus Safety, making it their strategic safety platform of the future.
Upgrade to latest version of the platform has always been a challenging task for many sponsors, given the complex nature of configurations, customizations and integration with various clinical, regulatory and safety applications in the R&D ecosystem. Typically it takes anywhere between 1 to 3 years for customers to get onto the new release after the version is available. Of course this time line will change with the amount of changes the new version brings to the table. The impact of change will also determine the duration of the upgrade project/program. This has been the root cause for many customers delaying the upgrades in the past. Not to mention the cost associated with these upgrades.
The latest release, Argus 8.1 addresses new regulatory compliance requirements, functional enhancements and biggest of them all technology platform currency. In my opinion,these three things are key drivers to upgrade to Argus 8.1.x .
Regulatory Compliance Requirements: The new E2B (R3) reporting guidance for transmission of Individual Case Safety Reports based on Health Level-7 (HL7) messaging protocol provides an advantage to capture more data with increased granularity and frequency. ICH E2B(R3) is a mandatory regulatory requirement that all safety organizations need to be compliant with, in future. Different Health Authorities have different milestones / timelines for compliance. At this time it appears that PMDA (Japan) deadline of April 1st 2019 as the most impending one. Also many sponsors have implemented interim solutions to process EMA’s Eudravigilance ICSRs that are available in E2B (R3) format. The interim solutions have to be done away with and what better than meeting this requirement through the core platform. Also, electronic Vaccine Adverse Event Reporting System (eVAERS) and electronic Medical Device Reporting (eMDR) requirements, connected with E2B (R3) and important initiatives for Vaccines and Med Device sponsors are key requirements to be complied with.
Bug Fixes and Functional Enhancements: As with any of the past releases, Oracle has also addressed a lot of requirements pouring in from sponsors to fix some of the existing issues and enhance the platform to meet some new requirements. In 8.x there are over 350 Issues fixed. New Expedited Report Updates adhering regulations are added. There are also various Case Management Updates. There are a bunch of changes specifically targeting Argus J (i.e. Japan). Japan Development Safety Update Report (JDSUR) is enhanced replacement for ‘Clinical Study Periodic Safety Report’ (CSPSR). Also, ability to convert existing CSPSR report to JDSUR on Copying the Existing Report has been added. There are updates to PSR, ReSD, Global Lock and local data locks and local case data locks specifically for Japan.
Technology Platform Currency: Many existing technology platforms that support Argus platform have become outdated in the last few years. This has led to Oracle adopting newer versions of Windows, Oracle Database, OBIEE, Axway Interchange, Oracle B2B (new) etc. Also, some of the legacy technology platforms like Windows 2008/R2 are going out of support, not to mention premium support for Argus 7.x as well. The Technology platform changes themselves should be a big reason for sponsors to consider upgrade to 8.1.x.
More specific details around the bugs/enhancements as well as specific software versions in the technology platform currency can be found in Oracle Argus Safety 8.1 Release Notes.
As always, your feedback and comments are welcome. I would be very interested to hear from consultants and technologists in the trenches, driving the upgrades. Also from sponsors who are considering upgrades in near future (or not) .
P.S: This is my first post after a very long hiatus. But I plan to share my thoughts and opinions more often going forward. Thanks for your support and feedback.
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.
In the last three years, I have seen a lot of customers migrating, upgrading or switching to Oracle Argus Safety. In this context I thought I will share my 2 cents about some of the key considerations for the teams driving the transition.
Oracle’s Argus Safety Platform is evolving and will continue to evolve over the course of the years. We have come a long way from the erstwhile Relsys days of Argus 4.x to more recent Oracle’s 7.x releases. During this journey, a lot of customers who bought into the product may or may not have moved on to the new versions. This, combined with typical technology currency lethargy associated with Life Sciences organizations (for obvious reasons) has made it a very difficult transition for sponsors using Argus. The other category of customers include ones with either a custom application (typically home grown) or one of the other safety suites (ARISg, AERS, Trace etc.). The transition for these customers is even more tedious as this may involve changes at multiple levels.
Irrespective of the source system, the transition is a long journey with various roadblocks along the way. In this context, I would like to highlight some key considerations for the team’s leading this transformation. The diagram below highlights the topics I consider as critical items, in my opinion:
If you consider the generic aspects (non-Safety) of a transition like this, one area that stands out is “Change Management”. Also, the change should be managed across multiple functions of the organization. Based on my experience with typical organization setup, across multiple sponsors I have worked with, the most common layers are: Business Process Services, Business Support (Help Desk & Product Configuration can be combined in this category) and Application Support. Let’s look at key aspects, from a Change Management perspective for the above three layers below:
- Business Process Services:
- Process Re-Engineering: This is one of the most critical parts of the transition. More so, if the sponsor is moving from a non-Argus environment to Argus. Many a times customers try to configure their existing business process. Despite Argus being a configurable system, this may not yield optimum outcome. Therefore, process re-engineering is a critical activity to be undertaken.
- Process Standardization: In the current world of mergers and acquisitions, it is not uncommon that an organization may have multiple safety systems. This might be the case across geographies (typically Japan). Hence, for organizations that desire a global Argus system (even though Argus Safety and Argus Japan are two modules in the Argus suite) it is essential that they consider standardization of processes. This will be particularly useful in being able to provide better support to the system and also simplifies the business process across the organization.
- Global Compliance: While “One Size fits all” may not work. It is always good to think about global compliance needs when setting up the business processes, procedures and personnel. This is more relevant when Argus is chosen as the Global Drug Safety tool of choice
- Business Support:
- Learning Management: Many of the personnel in the safety organization would need training on Argus Safety. This may not only require product training but also process training, in the context of Argus.
- Configuration Management: This in itself will be a huge exercise, not only to migrate configuration data from existing system but also to transform the configuration to fit into Argus. At times this might require additional training to the staff and/or setting up of a new team to handle Argus Business and System Configuration.
- Known Errors and Work Arounds: Over a period of time the KEDB for the current system would have grown to a huge extent and might be leveraged to improve response times for any incidents. There should be plans made to reuse and or seed the new Known Error Database (KEDB) with some standard information that can be provided by either Oracle or other sources.
- Application Support:
- Sourcing Strategy: Argus skill set is required to effectively support the product. This may mean looking for a different vendor from the one that might be supporting the current system. This might be the case even if the system is currently being supported by the sponsor, using internal IT personnel.
- Support Transition: This is one of the critical activities, if not done right, will not only sets back the entire transition but also may result in fines, if the AEs are not reported to regulators in time.
- Operational Efficiency: The existing team will be operating at an optimum level. This may also be true in terms of tools and accelerators developed over a period of time by the current team. The transition will force the efficiency to take a hit. So, it is essential to account for this change and plan accordingly.
While the above items only correspond to the Change Management, I will post my thoughts on the remainder of the considerations in subsequent posts. As always, I will be happy to receive feedback and inputs from you.
Adverse Events / Adverse Drug Reactions are imperative to all interventional therapies, be it drugs, devices, vaccines or biologics. The frequency, seriousness, breadth etc. may vary from drug to drug, person to person. We have made a lot of progress in ensuring that all the adverse events are identified, processed and reported to regulators. However there are still a lot of challenges in ensuring consistency, of how this is done across organizations, in terms of people, process and technology.
Oracle’s Argus Safety Suite is a leading drug safety system in the market. It is a very good application with rich features. However, there are still certain functions, the industry needs, that needs to mature and some others that are still evolving. I would like to write about one such features i.e. Adverse Event Reconciliation. The module in Argus Suite that provides this functionality is “Argus Reconciliation”. The datasheet lists the benefits of reconciliation and the ability of this module to make it easy, to reconcile the AE data between Argus and other Clinical Data Management systems.
What is reconciliation?
Reconciliation is typically the process of identifying any discrepancies in the data captured for the Adverse Events in Clinical Data Management system and Safety System.
Why do they have similar data in two systems?
Adverse event data is captured in CDM systems as part of the clinical trial data collection process. This data is also entered in Safety Systems in order to capture, process and report it to regulators. Sponsors should ensure that the data that is submitted to regulators during the course of the trial and the data that is submitted as part of the overall submission are consistent. Hence, reconciliation of data is essential. Ideally this situation should not arise if the data is collected electronically and the systems are integrated so the information flows bi-directionally. However, that is not the case in real world.
For customers that have Argus Safety there are essentially three options for reconciliation:
- Automated (COTS) and
- Automated (Custom)
Manual: This method, to a large extent is self-explanatory. One has to extract the AE records from the Safety and CDM systems and compare the data elements line item-by-line item. Any discrepancies identified may lead to a) change to the data in CDM system or b) change to the data in Safety system
Automated (COTS): This method can be used in case a commercially available integration exists between the CDM system and Argus. If we look at some of the popular CDM systems in the market, InForm (Oracle), Oracle Clinical and Rave (Medidata) two are from Oracle. The following information outlines the integration in case of each CDM system:
1) In case of Oracle Clinical, the reconciliation is available through the Argus Reconciliation module. Customers have to buy licenses to this module as part of the Safety Suite in order to leverage this functionality.
2) For Inform to Argus integration, Oracle has released a Process Integration Pack (PIP) that is part of their Application Integration Architecture (AIA), which in turn is part of their Fusion Middleware strategy. This essentially requires customers to install an AIA foundation pack and then purchase the PIP (Oracle® Health Sciences Adverse Event Integration Pack for Oracle Health Sciences InForm and Oracle Argus Safety) and install/configure it.
3) Medidata Rave’s Safety Gateway product can be leveraged for integration between Rave and Argus Safety. This is basically an E2B based integration.
Automated (Custom): In cases where the volume of cases is very high, which eliminates the manual option, and a COTS integration does not exist, customers may have to rely on a custom integration. This can be accomplished in multiple ways. However, an E2B based integration is recommended.
Hope this post helps you get basic knowledge about AE reconciliation and options available for reconciliation between Argus Safety and three popular Clinical Data Management systems. As always, your feedback will be very valuable and welcome.