In the last month at least 3 clients (top 10 Pharma) that I spoke to brought up Automation in the context of Regulatory Affairs. While it is very common for everyone to get excited about some of the popular technology trends and jump on the bandwagon to adopt these within a business context, many such initiatives fail to find traction and success unless they are carefully managed with a strategy and plan.
Regulatory Affairs function is not immune to this temptation. However, the excitement is typically tampered by the implications of things not working out resulting in regulatory compliance issues and product approvals. However, many activities within Regulatory Operations are repetitive in nature and are very conducive to being considered for automation. In my opinion, the criteria that should be considered while assessing a business process for automation are:
- Process Type: Nature of the Business Process in terms of Strategic vs. Tactical
- Frequency: How frequently is the process invoked to deliver business value
- Manual Tasks: How many tasks within a process are manual in nature and are leading to process inefficiencies and errors
- Benefit: How much hard/soft benefit can be delivered by automating the tasks
- Performance: Can the steps be measured easily to assess the performance
Assessment & Prioritization:
To create a strategic plan for automation, each process in Regulatory Affairs ranging from Regulatory Strategy to Life Cycle Maintenance can be assessed based on these criteria.
Prioritization of the processes and/or tasks within a process can be done by arriving at a balanced scorecard for automation. The weightages provided in the chart can be used as reference but can always be tailored based on any given organizations’ needs and inputs. The criteria can also be leveraged at the enterprise level to assess other functional areas like Clinical and Safety, in order to prioritize at the department level to assign and approve budgets. The key is a structured way of identifying opportunities, assessing them for automation ability and prioritizing based on balanced scorecard.
The above score card does not cover all the processes of the Regulatory Affairs processes. However, it is used to illustrate how to create a balanced score card to prioritize the processes for automation.
While organizations are considering moving to a Regulatory Information Management platform of the future, they can still consider automation as a way to compliment process improvements achieved. In fact, I strongly recommend creating an ‘Automation’ workstream as part of the RIM initiative so that all the work done to harmonize the processes and transform the processes in preparation for new platform adoption can be harnessed to assess and prioritize the processes for automation with minimal impact to ongoing work.
In a subsequent post, I will look at the processes within Regulatory Affairs that can be prioritized over others, based on my experience. I will also look at potential use cases within each process.
One of the cool things about being part of technology industry is living through certain hype cycles. I have experienced, in past 20 years of my professional life, ups and downs that tend to get everybody riled up about ‘this is going to end the world’ dooms day scenarios like Y2K to ‘this can do everything’ conversations about things like Artificial Intelligence, Virtual Reality etc. I still remember back in the day when my friends in the Computer Science branch in college had subjects like Virtual Reality, Neural Networks and Artificial Intelligence. I am talking about 1994 – 1998, which is almost 2 decades+ to the day. Not many of them pursued their careers in those areas, but it is amazing to think that it took as long as it did to get to current developments in this space that is revolutionizing the consumer and enterprise software industry.
There have been many developments along the way that got us here from Internet to client / server technologies to cloud to big data to NLP, to name a few. Today we can genuinely claim there are things that machines can do, faster and cheaper and more than anything else, SMARTER than humans with very little to no intervention from us. As BigData hype reaches a plateau, Deep Learning is picking up steam and more and more companies are investing in this area to genuinely unleash the power of data through smarter analysis with help from neural networks, NLP, Deep Learning and the likes.
Having spent considerable amount of time dealing with Life Sciences industry for the past 14 years, I can speak to the utmost conservative approach these companies take when it comes to technology adoption. It is a heavily regulated industry and rightfully so since it deals with human lives. Life Sciences companies can release life saving ‘Elixirs’ but can also unleash ‘Drug from the Devil’. In my experience Life Sciences companies typically are 2 to 3 years behind in terms of technology adoption. This may change depending on the department within the value chain but this tends to be the average duration before they use the latest version of Windows or IE or Office.
I hope to highlight some of the use cases where newer technology developments can be leveraged in Drug/Device/Vaccine development, specifically in the areas of Regulatory and Safety in a series of posts starting with this one. I will try to prioritize areas where there is a lot of manual intervention (Compliance) as well as areas that could leverage technology to deliver faster ROI (increase Revenue) and improve Operational Excellence (Reduce Cost).
One of the first areas that I thought could benefit from these technological advances is Regulatory Intelligence. The EU Regulatory Intelligence Network Group (RING Europe) defines it as “Regulatory intelligence is the act of processing targeted information and data from multiple sources, analysing the data in its relevant context and generating a meaningful output – e.g. outlining risks and opportunities – to the regulatory strategy. The process is driven by business needs and linked to decisions and actions.” RI is a key part of Life Sciences industry primarily for three reasons:
- It is a heavily regulated industry
- If companies operate globally they ought to comply with ever changing regulations and
- Influence policy and advocacy of future development
Please refer to this presentation from Carol Hynes of GSK for more details on “Regulatory Intelligence: Implications for product development“.
Many organizations have built Regulatory Intelligence Repositories by collating information from various sources. The diagram below represents various sources of RI data (courtesy : Regulatory Intelligence 101 By Meredith Brown-Tuttle).
These repositories cannot be built overnight. They have to be collated piece-by-piece over a period of time. The sources could go beyond the ones identified in the above diagram. Also, the repository may contain structured as well as unstructured content and data. Extracting information from such repositories is typically not a straight forward process. It definitely will not be as easy as asking a colleague who would then manually conduct the research needed and collate the information that can then be circulated to one or more individuals in the Reg Affairs organization for consumption and decision making . Therefore leveraging Automation, Machine Learning and Natural Language Processing in order to glean into the information in such repositories will make the life of Regulatory Intelligence colleagues lot easier. They can easily query the repository in their language of preference (for regular users with NLP capabilities) or write No-SQL and Semantic queries (experienced/super users) to extract the relevant information.
Information thus obtained can be leveraged to put together documents, newsletters and other communication vehicles which in turn could be stored back in the repository thus continually enriching and expanding the wealth of information available. This idea can be extended to create a federation of such repositories (internal, external, partners, vendors etc.) that can be scoured for the necessary information. Also leveraging even more advanced technology advances like Deep Learning might enhance the effectiveness and Return on Investment even more.
As always, your feedback and comments are most welcome. Thank 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.
Many large Drug Safety organizations have initiatives to leverage the historical data available to them and measure the operational inefficiencies of their processes. In my opinion these initiatives are worth spending your dollar. With the increased scrutiny by regulators on patient safety, drastic increase of data sources and dwindling budgets, the more you know about how good or bad you are at managing your processes to handle safety cases is worth the investment.The challenge always is with deciding what do you want to measure beyond your typical KPIs that you’d get from standard reports made available by the drug safety system vendors. Also, how flexible is the tool in making it easy for your team to define additional KPIs, create dashboards/reports and combine historical data with current data to perform comparative analysis.
Oracle has quickly established themselves as a leader in the Drug Safety space through acquisition of Relsys and Phaseforward. They probably have 3x the customers compared to their nearest competitor for all of their three safety systems. While this creates confusion in the short term, Argus Safety is emerging as the strategic product that they would support and continue enhancements in the long run. One of the initiatives that has come to fruition around this tool is Argus Analytics (formerly Oracle Pharmacovigilance Analytics ot OPVA) which has been available as a general release for close to 2 years now. While it demands additional investment from sponsors, I think it is a good starting point for any sponsor or CRO trying to measure their operational efficiency, identify bottlenecks and improve their decision making process.
I will keep this post brief and not go into the details of each KPI/Dashboard that is available in Oracle Argus Analytics and give a list of dashboards available. Many of these are self explanatory. More information can be found in the user guide available online here: http://docs.oracle.com/cd/E35225_01/doc.11/e29106/toc.htm
|Case Processing History||Trailing||Enterprise ID||Case Processing Volume History|
|Case Processing Compliance History|
|Workflow State Repetition History|
|Case Processing Management||Current||Enterprise ID||Case Processing Volume Management|
|Case Processing Compliance Management|
|Workflow State Compliance Management|
|Personal User Dashboard||Trailing & Current||Enterprise ID||Personal User Case History|
|Personal User Case Management|
|Personal User Case Work History|
|Personal User Expedited Report History|
|Personal User Expedited Report Management|
|Expedited Report History||Expedited Submission Volume History|
|Expedited Non-Submission Volume History|
|Expedited Submission Compliance History|
|Expedited Report Management||Expedited Submission Volume Management|
|Expedited Submission Compliance Management|
|Expedited Failed/Pending ACK Volume Management|
|Case Work History||Case Modified History|
|Case Unmodified History|
|Case Read History|
|Case Idle History|
Hope this gives a high level idea about the various dashboards available in Argus Analytics.
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.