In a resource constrained environment, pharmacovigilance departments should leverage technology in a highly efficient manner in order to achieve the best results for patients and for the business. This means focusing on such aspects of a safety system as impact of the continuously evolving regulations, integration of new data sources, reliability and scalability.
On the 11th of October, we hosted a complimentary webinar titled “Best Practices for Choosing the Right Safety Database”. During this webinar, we proposed a consistent and cost-effective approach for small and medium companies to choosing the right safety database. We will discuss how to balance the need to be aligned with continuously evolving regulations with scalability and cost considerations and will share the best practices for choosing the solution that fits company’s needs the best.
Continue reading to discover the questions from the Q&A session of the webinar.
Register today to get access to the webinar recording
During the webinar you have presented 3 Safety Database models: software to be installed from scratch or preconfigured solutions to be implemented in hosting or on premises and SaaS solutions. Do you foresee a 4th model?
During the webinar we presented the main approaches to the software supply that we are directly managing and that we meet in the market. Nevertheless, every vendor and/or provider could define its own preferred market approach that could be totally different from what we have presented. It can also be a a mix of the presented approaches.
For example, in our presentation we talked about the SaaS as a model suitable for small and medium companies, but the latest trend in the market is that some of the safety databases top-market leaders propose SaaS/Cloud solutions also for big companies.
We did not approach this topic in our presentation because moving to this type of database adds complexity to the vendor selection process that requires an approach to the selection different from the presented ones. Even if the technology is ready for this approach, the network of consultants, system integrators, and support companies is still immature, and these aspects should be carefully considered during the vendor selection.
In a pre-configured system, is it still possible to have some customisation (and of course OQ testing on this specific customisation)?
The choice of a preconfigured system is usually done in order to reduce the implementation costs and speed-up the setup phase. Nevertheless, you could implement specific configurations, customisations, integrations, considering the relevant costs for re-testing (if needed).
The key points to be considered are:
- The impact of required changes. If a complete/massive re-testing of the solution is required (e.g. in case of workflow major changes), approaching an installation from scratch could be preferable
- Avoid Customisations. Customisations could provide adherence to your current requirements, but iat the same time they can incur unpredictable costs for the future. Top market leader software solutions are usually configurable and allow to adapt the system functionalities to your needs without massive system changes (or integrations with external software or code).
In this manner you can mitigate the risk to lose your customisation or of generate data inconsistencies in case of future upgrades. In addition, configurable solutions can be easily changed in order to support evolving business and regulatory requirements.
You spoke about modular solutions supporting AI. Will this become a mainstream solution?
AI is definitely the future of safety databases. Pharmacovigilance is evolving, moving from a manual, reactive process to a proactive source of insight.
Robotic processes (Rule-Based/Static technologies) are already available and established in the safety databases.
Database vendors are nowadays upgrading their platforms with AI-based static technologies that include components that are AI-informed. These databases must be trained to imitate human way to sense, learn, deduce and communicate in the pre-release phase.
These technologies are the tools that can be added to your application suite or modules of integrated platforms, but the main software development trend is to define unified platforms that provide unified architecture and data model that reduce support and maintenance complexity.
But this is only the starting point. The software vendor market is strongly investing in R&D projects on AI-based dynamic systems (components that are AI-informed and capable of continuously adjusting their behaviour also in production phase using a defined learning process).
The main obstacle for the widespread use of these system is the regulatory environment: while rule-based/static technologies (RPA) follow the current system validation rules, AI-based static technologies require the extension of the current validation guidelines.
Vendors, companies and regulators as part of the same ecosystem should work together to streamline and speed up the process and to create guidelines tailored to the new technologies.
How should I approach the software selection process?
Successful technology vendor selection in the Life Science environment requires the right level of resource commitment, coordination with the business, and due diligence.
Technology vendors choice for vigilance is a strategic matter, since complex data flows, decentralised environment, regulatory focus on data quality and integrity are expanding the traditional roles and processes.
The companies could improve the results and minimise the risks through a structured vendor selection approach, which should start with a kick-off meeting.
The kick-off meeting aims at defining the project scope, stakeholders, the communication flow and tools, and at collecting available SOPs about the process. Following the kick-off meeting you should define your Project Plan with tasks and calendars/timeline in which you want to complete the vendor selection.
Then, you should approach to the elicitation phase. To collect the requirements, you should organise interviews to the main stakeholders.
- To avoid delays, opt for the interviews instead of asking for documentation drafting
- Define an interview template document to collect information about the requirements of the main stakeholders
- Take into account two strategies: high-level strategy of your company and IT strategies (for example your IT want to install new systems on premises to reduce the internal IT effort)
- Conduct the interviews filling in the template with collected information
Before drafting your business requirement document, it would be useful to translate the collected requirements in a high-level solution design, supported by the graphical representation of the desired system workflow.
The result of your analysis can be presented and approved by the main project stakeholders before drafting the business requirements and starting the selection process.
As soon as your workflow has been approved finalise your Business Requirement document. This document represents the starting point of the vendor selection process. You can submit your requirements to many market vendors identifying who and how can satisfy your requirements.
Do the safety databases on the market have Artificial Intelligence functionalities? Is this a key driver for choosing a safety database?
Top market leaders provide systems that support small process automations that mainly support case assessment, distribution & reporting phase.
Before starting investing in AI/new automations the suggestion is to try to optimise the existing automations through proper system configuration/usage. Our suggestion is to choose a safety system based on its scalability.
“Nice to have” extensions include:
- Case intake phase: Duplicate Check, Prioritisation/Triage
- Case processing phase: Full Data Entry and Medical Assessment
Do you have other questions related to choosing the right safety database for your pharmacovigilance department? Contact us and we will get back to you with an answer as soon as we can.
