For as long as I have known the regulatory tools market space, it has been much more fragmented that it’s peer business functions such as Clinical and Safety. If you take the Regulatory Affairs value chain from Strategy / Submission Planning all the way through Archival, many sponsors use different products / platforms / tools for different functions. Typically you would see a mix of Excel/Spreadsheets to established tools for regulatory document & content management as well as publishing, submissions and archival. This is in contrast with Clinical and Regulatory space where you would typically find 2, if not 3 platforms that can cater to a major portion of the value chain. More than Clinical I would say Safety is probably a better in example to highlight this situation where you’d most likely find 2 products ruling the roost in Oracle Argus and Aris Global’s ARISg (LifeSphere Safety).
This situation in Safety platforms space was not achieved overnight but rather over 5 – 7 years through market consolidation. Oracle essentially bought off all the other reputable and competing tools in the market leaving only ARISg to compete with. Off late there has been a similar trend in the regulatory market with some of the niche tool providers like Octagon, ISI etc. being acquired by larger players like PAREXEL, Accenture, and CSC. While this has resulted in consolidation of the tools/platforms under a smaller set of vendors, these tools still need lot of integration to make them work together. There are vendors like Veeva (Veeva Vault RIM) that have taken a different approach to this problem and have reached a point where they can claim more cohesive platform that integrates out-of-the-box, and as is the case with Safety platforms, caters to majority of the functions in Regulatory Affairs value chain. However the jury is still out whether some of these platforms deliver the value they are expected to since the adoption has just begun and long term use is still not proven.
With the advent of Cloud solutions and adoption becoming a reality in Life Sciences R&D, even though it is much slower as opposed to other industries and even departments within Life Sciences for regulatory reasons, platforms on the cloud with coverage across the Regulatory Affairs value chain can get us closer to RPaaS. The reality of budget challenges across many Life Sciences companies is going to force the issue. For Platform vendors like Veeva and Aris Global the key is interest and willingness to invest by their clients. It will not be a win-win proposition unless each party can look forward to cost reduction, productivity improvement, technology currency and regulatory compliance through these platforms.
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.
Over the last 3 years, I have come across several initiatives from life sciences companies to revisit their Drug Safety system strategy, in line with the trend of evaluating their options with other IT systems, on whether they should continue to host and support these systems on-premise or move to cloud. We all have witnessed a major shift towards Cloud Computing and Software-as-a-Service (SaaS) model, Drug Safety is no exception. The challenge with this strategy is that it needs a dramatic shift in the traditional thinking that prevails in the industry in terms of people, process and technology. What I mean by that is:
- People should understand that once the system is hosted by an external partner, the way the business and IT teams within the sponsor organization interact with the support teams will change dramatically. For example, they may not be able to pick up the phone and call a Mr. John Doe at the last minute to get their product/license configured in the safety system to support the launch of a new study.
- Processes, both business and support, should be changed to reflect the new model and ensure seamless transition and steady state support to ensure the business operations are not impacted. For example, if you are engaging a new partner in a new market to support your clinical study you have to engage the service provider so you plan and support the onboarding process in time.
- Technology should be brought in to accommodate such change and ensure business continuity, system performance and transparency in service delivery. For example, tools should be made available to not only monitor the performance of the system and process but also to continually review and improve the performance.
You may argue that these are required for any transition from “On-Premise” model to “SaaS/Hosted” model. My answer would be YES, but the regulated clinical research world adds additional emphasis on getting it right the first time and ensuring that every aspect is validated and in compliance with the regulatory requirements of various agencies across the sponsors markets. I want to list some key items that would be useful to sponsors, in evaluating Drug Safety System hosting partners.
- Domain Expertise: The first and foremost criterion is “how much does the partner know about Drug Safety?” You cannot go to run-of-the-mill hosting partner and expect them to understand your business processes and host the system in compliance with the regulatory requirements
- Hosting Expertise: Have they hosted a safety system for any other customers? If not, have they hosted a system that requires validation and should comply with regulatory requirements? Will it be a “Multi-tenant” environment? If so, do they have experience facing audit for such a setup as my data may be hosted along with my competitors? How do they ensure Data Privacy and Security? Does their system support Single Sign On (SSO) or do my users need a separate login to access the system, which could be disruptive to business
- Hosting Location: Where are they hosting my data? Some countries do not allow safety data of patients to reside on foreign soil for obvious reasons. What arrangements do they have from a Disaster Recovery and Business Continuity perspective? How do they staff in case disaster strikes the main site? Do they move people or do they maintain minimal staff to support the secondary site?
- A-Team: Do they have the right people? If so, what are their qualifications? In my experience many sponsors look for references of the partner. That may not always be the right way to evaluate the partner because the staff that delivered the project for that referenced customer may not be with the organization anymore. Most service providers in drug safety space have small teams. Not all of them have bench strength to fully staff the engagement. However, it is critical that they have senior staff to seed the team and bring on additional staff as needed
- Processes: Do they have SOPs and WIs to get the new environment up and running faster but with little risk? Can they also provide case processing and aggregate reporting services? If so, what processes do they have in place? Do those processes meet our requirements? If not, how do we harmonize the processes?
- Total Cost of Ownership (TCO): It is essential that a decision of this criticality is financially viable too. Also, it is required to have a long term view of the cost associated with such a move. It is highly impractical to change your decision in short intervals of 1 to 2 years. You should be committed to a term of 3 to 5 years. If you are, then what is the total cost of ownership for such a commitment? Is the vendor transparent about all the hidden costs? If there would be increase in pricing, how predictable is it? Can we lock-in to a price now for 5 years? What discounts are offered? Can we tie in the payments to service performance? How about service credits?
- Viability: It is critical that the partner has a viable business model. Not just to fulfill your current needs, but your future needs as well. If you expand to new markets, would the partner have ability to support such a change? Do they have teams spread across multiple geographies?
- Cultural Fitment: You need a partner that fits, not just from a strategic and operational perspective but also from a cultural perspective. This arrangement is long term and both parties should look at it as a win-win proposition and should be committed to make it a success.
- Executive Commitment: Last but not least is the commitment the partner has to this business and more importantly to your service. What is their governance model? How does the escalation process work? Where is the executive team located? Are they a phone call away, if disaster strikes?
These are some of the aspects that I thought would be useful for some sponsors and vendors alike, to consider when selecting a partner for a drug safety hosted service. As always, appreciate your feedback and comments.