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.
I was looking at the FDA report from Sep 2014 titled “Standardizing and Evaluating Risk Evaluation and Mitigation Strategies (REMS)” to better understand the need for the new DRAFT guidance to submitting REMS using SPL, as outlined in the guidance document issued in Sep 2017 titled “Providing Regulatory Submissions in Electronic Format — Content of the Risk Evaluation and Mitigation Strategies Document Using Structured Product Labeling”. I felt it would be easier for people to understand the need for the guidance if they understand the backstory leading up to the new guidance. Please refer to the original report and subsequent guidance for more details.
Feedback to FDA, through various stakeholder engagement sessions participated by vendors, healthcare community and other impacted groups:
- Stakeholders are not uniformly impacted by REMS requirements
- Communication about REMS requirements should be improved
- There should be flexibility to implement a REMS program based on the nature and variety of health care settings.
- REMS are vital tools that will be increasingly necessary, and content delivery must be streamlined without compromising the content itself
- FDA should standardize REMS across platforms, media, and delivery technologies and work to fully integrate them into health care systems—which will increase access by both health care providers and patients, and enable improved assessments to further advance standardization.
- FDA should use human factor evaluation approaches like Failure Mode and Effects Analysis (FMEA) to support and standardize REMS program design.
- FDA can improve REMS assessments with a variety of tools and techniques
- FDA should structure and standardize REMS information.
Based on engagement with industry stakeholders and the feedback received, FDA prioritized 4 projects in four different areas:
- Patient Benefit/Risk Information under REMS
- Providing Patient Benefit/Risk Information by Improving Tools for Prescriber-to-Patient Counseling
- Prescriber Education under REMS:
- Prescriber Education—REMS and Continuing Education (CE) for Health Care Providers
- Pharmacy Systems under REMS:
- Standardizing REMS Information for Inclusion into Pharmacy Systems Using Structured Product Labeling (SPL)
- Practice Settings under REMS:
- Providing a Central Source of REMS Information for Practice Settings
Of these projects, the project titles “Pharmacy Systems under REMS” led to issuing the guidance that is issued in September 2017 and distributed for public comments. The objectives of this project were:
- Make structured REMS information available to health care providers, patients, and FDA.
- Provide a single conduit of comprehensive information about REMS programs.
- Facilitate the integration of REMS into pharmacy systems and health information technology, including systems for electronic prescribing.
- Improve the efficiency of FDA’s review of proposed REMS by allowing the Agency to receive REMS submissions in a consistent format.
- Support FDA’s ongoing REMS standardization efforts by enabling the cataloging of similarities and differences between REMS programs.
The project’s final deliverable was set to be a revised SPL Implementation Guide that describes how sponsors, health care information system developers, and other stakeholders can share REMS information leveraging the existing SPL standard.
To help address the concerns expressed by various stakeholders, FDA wants to take steps to streamline the access to REMS information
- FDA intends to require applicants of NDAs, ANDAs, and BLAs to submit the content of their REMS documents in Structured Product Labeling (SPL) format
- SPL can be used to capture and present REMS information in a format that is:
- Easily shared with stakeholders and
- Readily incorporated into health information technology
- Twenty-four months after the final version of the guidance is published in the Federal Register, applicants must submit REMS documents in electronic format consistent with the requirements set forth below:
- Types of submissions : NDAs, ANDAs and certain BLAs
- Also applies to all subsequent submissions including amendments, supplements, and reports, to the submission types identified above
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 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.